Re: Document architecture: locking document files while open
On May 23, 2014, at 6:52 AM, Matthew LeRoy wrote: > ...and come up with a way to handle the scenario where > multiple users have the same file open. It's called client/server. Anything less is a dangerous kludge. (If you *knew* your file system had some kind of proper locking support, then it could be safe, but that's a tough requirement to meet.) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Document architecture: locking document files while open
On 5/22/14, 12:21 PM, "Jens Alfke" 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 (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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Document architecture: locking document files while open
On May 22, 2014, at 9:44 AM, Gary L. Wade wrote: > I've only just run across this as a potential solution to a prospective need, > but might Kernel Authorizations be what you need? > https://developer.apple.com/library/mac/technotes/tn2127/_index.html Only if you’re implementing your own filesystem as a kernel extension. That’s some scary low-level stuff there. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Document architecture: locking document files while open
I've only just run across this as a potential solution to a prospective need, but might Kernel Authorizations be what you need? https://developer.apple.com/library/mac/technotes/tn2127/_index.html -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ > On May 22, 2014, at 9:21 AM, Jens Alfke wrote: > > >> On May 22, 2014, at 8:51 AM, Matthew LeRoy wrote: >> >> Does anyone have any idea if there is a way to get the document architecture >> to lock a document file when it is opened? > > 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. > >> When I say “lock”, I’m talking about an exclusive file lock at the >> filesystem level, as in no other user or process can open, move, or delete >> the file. > > There’s no such thing in standard Unix. The closest thing is “advisory” locks > (i.e. flock(2)), which are opt-in and can be ignored, and only prevent > modifying the file, not opening/moving/deleting it. > > HFS+ does have extended attributes that, I _think_ include some sort of > “immutable” option, but from what you say below I don’t think that’s relevant > here. > >> This causes all kinds of kooky and undesired behavior if a document on a >> remote filesystem is first opened in the Mac version (which does not lock >> the file), then opened concurrently by the Windows version (which locks the >> file). > > 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. > > —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Document architecture: locking document files while open
On May 22, 2014, at 8:51 AM, Matthew LeRoy wrote: > Does anyone have any idea if there is a way to get the document architecture > to lock a document file when it is opened? 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. > When I say “lock”, I’m talking about an exclusive file lock at the filesystem > level, as in no other user or process can open, move, or delete the file. There’s no such thing in standard Unix. The closest thing is “advisory” locks (i.e. flock(2)), which are opt-in and can be ignored, and only prevent modifying the file, not opening/moving/deleting it. HFS+ does have extended attributes that, I _think_ include some sort of “immutable” option, but from what you say below I don’t think that’s relevant here. > This causes all kinds of kooky and undesired behavior if a document on a > remote filesystem is first opened in the Mac version (which does not lock the > file), then opened concurrently by the Windows version (which locks the file). 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. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Document architecture: locking document files while open
Good morning, Does anyone have any idea if there is a way to get the document architecture to lock a document file when it is opened? When I say “lock”, I’m talking about an exclusive file lock at the filesystem level, as in no other user or process can open, move, or delete the file. I’m not talking about the “Locked” attribute that is settable through Finder’s Info panel or the document’s title bar menu. The reason I ask is that my application has a corresponding Windows version, and the Windows version locks the document files when it opens them. This causes all kinds of kooky and undesired behavior if a document on a remote filesystem is first opened in the Mac version (which does not lock the file), then opened concurrently by the Windows version (which locks the file). At this point, I get all kinds of warning and error messages in the Mac application anytime autosave attempts to save the document, or if I attempt to save it manually. Unfortunately none of the messages explicitly state that the reason for the warnings and errors is that the file is locked by another user/process. Even attempting to close the document is unsuccessful if the “Ask to keep changes when closing documents” system setting is unchecked, because the application attempts to save the document, fails (because it is locked), and then aborts the close operation. The only way I have found to get out of the endless loop of warnings/errors is to choose File > Save As… and then un-check the “Keep changes in original document” checkbox. Ideally I would like to prevent multiple users from opening a document file at the same time. The document architecture seems to automatically fail to open a file that is locked at the filesystem level, and we’ve coded that same behavior in the Windows application as well, so the only piece of the puzzle missing is getting the Mac application to lock the file once it has been successfully opened. I’m guessing I could implement the locking code manually in one of my NSDocument overrides, but I’m worried about properly handling all of the various move/rename/duplicate cases and making sure I correctly release the locks when those things happen; would be much better if the document architecture can handle all of that for me, but I don’t know if it can. Thanks! Matt ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
