Thank you so much Ken, I would like to use the BSD/POSIX file access routines. May you give me a pointer?
Best Regards -- Lorenzo email: [EMAIL PROTECTED] > From: Ken Thomases <[EMAIL PROTECTED]> > Date: Thu, 22 May 2008 23:42:00 -0500 > To: Lorenzo <[EMAIL PROTECTED]> > Cc: Jens Alfke <[EMAIL PROTECTED]>, Cocoa Development > <cocoa-dev@lists.apple.com> > Subject: Re: DirWatch > > 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
