Re: How to know a file is writeable?
Re: How to know a file is writeable?
- Subject: Re: How to know a file is writeable?
- From: "John C. Daub" <email@hidden>
- Date: Fri, 25 Feb 2005 08:34:36 -0600
on 2/24/05 5:48 PM, Arthur VIGAN at email@hidden wrote:
> how can is know if I can write/delete an existing file?
Short answer: try it and find out.
Longer answer: There was actually a discussion about this very issue just
yesterday on another mailing list I'm on, and I think a bulk of it can
re-discuss here since it's mostly about stuff available in Panther. So the
following words are my own, but based upon information I received from very
reliable sources that would know about this sort of thing.
Others in this thread have suggested using mechanisms like access() and
NSFileManager's -isFileWritableAtPath: and -isDeletableFileAtPath: (which I
believe are either built upon or at least essentially equivalent to using
access()). And if you want to go with the Carbon File Manager, you can use
FSGetCatalogInfo() with the kFSCatInfoUserAccess bitflag. There are subtle
differences in these approaches tho, such as access() checks every component
along the path and I think FSGetCatalogInfo() will check just that
particular file/folder that you pass to it... so you have to choose which
behavior is appropriate to your situation.
But really, the best any of these mechanisms can give you is a hint about
the read/write/deletablity of that file. One thing is there's a possible
race condition in that in between the time you check if you can write/delete
and then actually do the write/delete that the accessibility of that file
could change. Another thing is how the permissions are ultimately determined
by the file system plugins and, without rehashing all the technical details
(see KAUTH_VNODE_ACCESS if you're curious), it's very possible that the
response you get back from these checks could end up being different from
the actual reality. That is, checks like access() could say one thing, but
then when you go to actually write/delete the file the situation ends up
being entirely different.
So really, all of those suggested approaches can only be considered a hint
and should not be considered authoritative. The best thing to do is just
allow the actual write/delete operation to occur, and then make sure that
your handling of that write/delete operation deals gracefully with errors
and unexpected situations... which it should be doing anyway, right? :-)
To give an example, let's say you're writing an application that does file
system browsing. The user browses to some directory, and it's reasonable to
use something like access() or the NSFileManager routines or the
kFSCatInfoUserAccess information to display a "slashed out pencil" icon to
say you can't write to that directory. If the user explicitly tries to copy
something into that directory via your app, you shouldn't just say no but
should actually try the copy. Thus the success or failure of the copy is
ultimately and properly determined by the file system.
So hopefully that can show that the hint stuff still has a place (cause it's
generally useful and typically faster to determine), but you just can't
consider those mechanisms authoritative. You just have to allow the
operations to happen and properly cope with the consequences.
--
John C. Daub }:-)>=
<mailto:email@hidden> <http://www.hsoi.com/>
"Ain't it funny how that money rots your brain?" - Pepper Keenan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden