Re: DirWatch
Re: DirWatch
- Subject: Re: DirWatch
- From: Ken Thomases <email@hidden>
- Date: Thu, 22 May 2008 23:42:00 -0500
On May 22, 2008, at 10:56 PM, Ken Thomases wrote:
On May 22, 2008, at 6:57 PM, Lorenzo wrote:
I can't.
Think about the FNSubscribe tells me that there is something new
because the
user copied 2 new files into that folder, but only one file is
totally
copied, the other one is still in copying. So now I scan the folder
with
directoryContentsAtPath
I compare with the previous list and I know that there are 2 new
files.
Well, one file is totally copied and the other one could be still in
copying.
You can try FSGetCatalogInfo() and the kFSNodeForkOpenBit of the
nodeFlags field of the FSCatalogInfo structure to test if the file
is still open. I'm not sure if this is supported on all filesystems
that Mac OS X supports. It's actually very unusual for an OS or
filesystem implementation to keep that sort of information in
application-accessible form.
The problem on a preemptively multi-tasking system is that the
file's status can change between when you test and when you act on
the results of the test. Generally speaking, sometimes the solution
to a race condition like that is to attempt to grab the contended
resource for exclusive access. If you succeed, you know that nobody
else was using the resource, nor will they be able to start using it
while you're using it.
Again, it's quite unusual for modern OSes to support mandatory
locking of files in this way. Most only provide advisory locking.
However, Mac OS X's File Manager still maintains provisions for it.
Once again, they may not work on all filesystems. In addition to
the File Manager Reference, you can check out Technical Note FL37 <http://developer.apple.com/technotes/fl/fl_37.html
>, although it's nearly archaic. (Not as archaic as the date it
claims, though! :)
OK, so none of the above actually works in the general case on Mac OS
X. I checked the nodeFlags thing myself with a little test program
and it doesn't work. The bits indicating if forks are open are never
set. Also, I found a more recent technote regarding exclusive file
access: <http://developer.apple.com/technotes/tn/tn2037.html>.
That technote, though, does indicate that the frameworks perform and
respect advisory locking. So, this is pretty good. It covers the
most common cases. The exception would be a program using the BSD/
POSIX file access routines directly.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden