Re: DirWatch
Re: DirWatch
- Subject: Re: DirWatch
- From: Lorenzo <email@hidden>
- Date: Fri, 23 May 2008 09:37:11 +0200
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@hidden
> From: Ken Thomases <email@hidden>
> Date: Thu, 22 May 2008 23:42:00 -0500
> To: Lorenzo <email@hidden>
> Cc: Jens Alfke <email@hidden>, Cocoa Development
> <email@hidden>
> 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 (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
| References: | |
| | >Re: DirWatch (From: Ken Thomases <email@hidden>) |