Re: DirWatch
Re: DirWatch
- Subject: Re: DirWatch
- From: Robert Cerny <email@hidden>
- Date: Fri, 23 May 2008 08:28:51 +0200
On 23.5.2008, at 6:42, Ken Thomases wrote:
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
_______________________________________________
I remember a utility which I wrote several years ago and I solved the
problem using timer. I had a preference setting allowing to set 'how
many seconds should I wait, until I take the file as complete'.
Robert
_______________________________________________
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