View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015727||Scribus||General||public||2019-06-27 19:34||2019-07-01 16:32|
|Summary||0015727: scribus should warn the user when opening a file that is already open|
|Description||a user is complaining that if a file is on a file server, it is dangerous to allow two users to open the same .sla file at the same time.|
"correctly" resolving the issue might be a bit hard to get right, but i think it would be easy to:
- add a field with the last user having being editing the file (or even keeping some sort of editing list),
- add a flag that is true when the file is currently open.
when opening a file, scribus would check the file and if it detects that the file is already open tells the user who has already opened the file and asks her to confirm that she really wants to open the file.
if the user decides to open the file (the computer might have crashed), the new user will become the current user.
the flag is set to false when the file is closed (also on quit...).
on save, scribus might check for the current user in the file and ask for a confirmation if it detects a change.
|Tags||No tags attached.|
Qt has a QLockFile class, unfortunately it seems it won't work well in this case: "Serialization is only guaranteed if all processes that access the shared resource use QLockFile, with the same file path."
Note the "same file path" part. That means if share is mounted differently, QFileLock will stop working correctly. Same if one user use Windows while the other is using Linux. Also nothing will prevent another user opening file with Notepad++ and editing it manually while some other user edit the file in Scribus.
>> "correctly" resolving the issue might be a bit hard to get right
>> add a flag that is true when the file is currently open
At least not in the scribus document itself: this would require writing file after opening it. That would led to interesting synchronization issues if two users try to open same file at same time, risking leaving file in a broken state. And if more than 2 users involved, that's not a bool we need, but some kind of reference counting, which means synchronizing access to the reference count.
So yup, such feature will be probably not only hard to get right, but likely also hard to get simply working.
somehow i still have the feeling that a naïve implementation is still better than the current status.
currently, you also risk to have a broken file if two people save the same file at the same time...