On 5/22/14, 12:21 PM, "Jens Alfke" <[email protected]> wrote:
>If you implement the lower-level read/write methods in NSDocument, you >have full control over opening and closing the file. You can then make >whatever filesystem calls you want to lock/unlock it. You¹re talking about readFromURL:ofType:error:, yes? As opposed to readFromData:ofType:error:? >OK, here it gets even messier, because you¹re talking about locking files >on a file server. This involves the semantics of the file sharing >protocol (you didn¹t specify what it is), of OS X¹s client implementation >of that protocol, and of the underlying > filesystem of the disk volume being shared. There are significant >differences between the behavior of NFS, AFP and SMB, and between >different versions of those, and different versions of OS X connecting to >them Š it¹s quite a rat-hole. I¹ve seen people give > vehement advice to _never_ use SQLite databases on shared volumes, for >example, because problems with file locking can easily cause database >corruption. > >At a minimum you¹re going to need to describe exactly what software is >involved on both sides, and what file server protocol is in use. In my testing scenario, I¹m running OS X 10.9.3 and the app is built against the 10.8 SDK. The file server protocol is SMB; I don¹t know anything off the top of my head about the server itself or the filesystem of the volume being shared, but I would guess it¹s an NTFS volume and a Windows server of some variety. The Windows client machine is Win7. I¹d previously read the SQLite documentation regarding file locking, including the bit about how some implementations of NFS and other protocols are just plain broken w/r/t file locking, so I already had an inkling in my head that this is a mess of a problem to try to solve. In that light, I think that I¹m going to look into removing the locking behavior in the Windows application instead, and come up with a way to handle the scenario where multiple users have the same file open. Thanks! _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
