[scribus] Multiple instances of Scribus

[Craig Ringer]

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