John Brown wrote: > The whole point of issuing a warning is to give the user a chance to > take some action. All Scribus has to do is give a warning that somebody > may be in the file (like vi). Whatever happens, well, it tried.
I missed your emphasis on using a lockfile to *warn* about an open file. Yes, if it's a warning that the user can bypass, vim style, then that's OK. Honestly, though, as a vim user I don't much like its lock file handling. It cannot tell the difference between "file is open elsewhere" and "file was open by process that exited uncleanly" because of the lockfile limitations I mentioned earlier. It'd be nicer if it'd automatically recover, or just offer to recover/discard, state from a known dead session. For end-user apps I prefer strong locking mechanisms that don't ask questions and don't offer to bypass the lock. That's a preference based on way too much experience with what happens if you give users an "open anyway" button. However, the user base I've suffered is not the same as the user base of Scribus, and perhaps for Scribus a lockfile and warning would be appropriate. It's worth noting that advisory locking, like fadvise(), can also be used to provide a bypassable warning, but works correctly on network volumes. > Which you don't want to do because it is too much work. The lock file is > less work, isn't it? I see three choices: 1) No locking. The user wants control. 2) Lockfile or advisory file lock and bypassable warning 3) Mandatory file lock or advisory lock used to enforce mandatory locking. No bypassing of lock. I think (1) is OK at present, and my concern about the time cost related to the implementation of any form of locking. If it's a choice between locking methods then I strongly favour (3). However, (2) can be done better using advisory locking at the OS level than it can by a lock file, if that does end up being the way Scribus goes. Note that other apps that users are used to, like OpenOffice, use a mandatory lock scheme. OpenOffice automatically opens the file read only if it's locked, offering the user no choice to open it read/write. >> QuarkXPress has an interesting spin on lock files. It creates a >> temporary file in the same directory as the original file, and holds an >> exclusive access file handle open on the temporary. Nobody else can >> create a temporary with the same name, so the file is "locked" that way. >> If the Quark user loses their connection the file handle on the >> temporary is closed and another instance can open it and offer to >> recover the unsaved work, or can just delete and recreate it when >> opening the file again. >> >> Scribus doesn't need such temporaries, so it makes more sense to just >> lock the original file if that's desired. > > You just rejected what seems to be an elegant solution. I don't see how. I see no significant difference between holding a file handle with an exclusive access lock on a temporary file as compared to holding the same lock on the original file. I probably shouldn't have mentioned this at all, but the point was that Quark uses proper operating system locks to avoid the issues with lockfiles. Quark uses the temporaries because it needs a temporary anyway, and as it's keeping the temporary open it might as well do it's locking on the temporary rather than the original file. Scribus does not need such a temporary (because it just does all the work in RAM - which has its own costs) and it can just as easily lock the original file. Operating systems provide file locking mechanisms precisely because application level locking using lockfiles is so limited. If Scribus is going to support file locking, IMO it's best to avoid a rushed implementation like a lock file and spend more time to produce an OS-level advisory or mandatory lock based solution. The platform specific stuff involved in locking is annoying, but it's nothing that cannot be bundled up in a single class that has alternate implementations for each OS. -- Craig Ringer
