http://coldfusion.com logo
Join Slack
Powered by
I'm probably misunderstanding how the getFileInfo(...
# cfml-general
d
I'm probably misunderstanding how the getFileInfo() 
canWrite
property works, or maybe this is a bug.
b
The permissions check is likely different from the file being locked by another process
d
Docs say 
canWrite: whether the file has write permission
.
b
Do you have some java code that opens an input stream on that file and doesn't close it?
Right, and the error doesn't say "permissions denied", it says "the file is in use by another process"
d
Oh I'm actually opening the file myself to test the 
canWrite
property. I know its open - but thats exactly what I want to find out.
I guess I have no other option but to catch the error
d
You mean you opened it using 
fileOpen()
? You don't need to do that to use 
getFileInfo()
. In fact, you should probably check the 
canWrite
property before you open it (assuming you do intend to write to it). Unfortunately, if it didn't get closed for some reason (via 
fileClose()
), then it may now be stuck in an open state, making it impossible to interact with until you reboot the server.
d
@David Buck no, I'm opening the files via file explorer, leaving the file open on purpose so I can figure out how to determine that it is open. canWrite is just a permissions check and I don't see a built-in way in cfml to check if the file is locked by another process SO I'm resorting to catching the error. At this point I wish cfml errors had specific error codes - instead I have to regex find kewords.
d
Aaah, ok now I see the problem.
a
At this point I wish cfml errors had specific error codes
Or - wild wild idea here - actually had exception types. Now there's a crazy idea that no-one has ever thought of before. 😐
💯 1
😂 1
That said, I'd've thought the 
canWrite
value would be agnostic to the underlying reason why a file might not be writable, be it perms or it being already locked open? If you can write to it, you can write to it. Isn't that what you care about? Or is it returning 
true
even if the file is in use by another process, or something?
That said, I would perhaps approach your dilemma along these lines:
Copy code
try {
    // open it for writing
    // write to it
} catch () {
    // deal with it
} finally {
    try {
        // close it
    } catch () {
        // deal with _that_
    }
}
Job done?
d
@Adam Cameron I did some testing earlier, and it appears 
getFileInfo()
does just check for write permission like Daniel said (actually, I'm not even sure it checks permissions-- it may just look at the readonly property).
a
Yeah I was about to ask if you meant "perms" or just that attribute
Still. What I think you want is to write to the file right? Yer less fussed about the value some function call returns about whether it's writable or not?
So just... try to write to it. If you can? Sweet. If not... "I kinda expected that..." is fine.
➕ 1
I mean what were you gonna do if you were accurately detect that you couldn't write to it?
d
@Adam Cameron @David Buck canWrite returns true/false based on perms, and yes it doesn't matter that the file is being used by another process. So you are right that I want to be able to write to the file. So check this. After I started this post I went with catching the error. Which is what you suggested Adam. But earlier today I changed that to avoid all of it. I now create unique named files. So my users can run the process, open the generated files straight from the network share, and rerun the process again without worrrying about "open" files.
d
It's always nice when a roadblock forces a detour that turns out to be better than the original route.
3 Views
Open in Slack
PreviousNext
Powered by