John Brown wrote: >> That's a lot of platform specific messing around, though, for a pretty >> trivial feature. Personally I wouldn't bother. >> > > A simple way would be to create a lock file the sole purpose of which > is to indicate that Scribus has already opened the file.
Lock files are IMO about the *worst* way of doing it. If Scribus crashes, the lock file may not be cleaned up (depending on whether or not the crash handler can run successfully). This is OK on non-networked storage, because we can store the process ID in the lockfile and see if there's a Scribus process with that ID running. If there isn't the lockfile is clearly stale and can be removed. On network storage, however, we cannot test to see if the lockfile creator is still running. In fact, even if the lockfile creator is still running, it might no longer have access to the network volume. That leaves the poor user to deal with the mess. Avoid lock files at all costs. If locking is required, it's much better to use the advisory or mandatory locking mechanisms provided by the operating system. 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. Also: Libraries and such should not be locked, as ideally it should be possible to share them. -- Craig Ringer
