Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


When tweaking lock files naming, please keep in mind why the lock files are used in the first 
place. One of their goals is telling other programs (it means, other LibreOffice/AOO/OOo instances 
opening same files from other sessions/boxes) that the file is in use (when OS/FS doesn't provide 
reliable FS locking), and also some basic information on who/where is using the file (so that it's 
possible to identify and do something sensible with that).

Changing a lock file name means that all the other programs (e.g., old LO or AOO) will not be able 
to detect the lock files. Also, current LO would not be able to detect those legacy lock files, or 
will need to have more complex code to write/read two lock files.

I'd say that writing a "safe" lockfile name *after* unsuccessful attempt to create a normal 
lockfile, *and* making sure that the normal lockfile is absent (so that the failure is not because 
of already-locked file)... could be ~reasonable (because that would mean that normal lockfile name 
is unavailable, so legacy soffices would not be able to use usual locking there anyway). But that 
is not just a "let's change our name for all cases" approach.

And oh, this will introduce more complexity to our fragile and already too complex locking code... 
well - that may be worth it; see [1] for another example of situation where certain characters are 
prohibited and locking fails.

Thank you for consideration.

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=115747

--
Best regards,
Mike Kaganski.
________________________________
От: LibreOffice <libreoffice-bounces@lists.freedesktop.org> от имени Olivier Tilloy 
<olivier.tilloy@canonical.com>
Отправлено: 13 июля 2018 г. 3:36
Кому: libreoffice@lists.freedesktop.org
Тема: leading dot and trailing # in lock files

Hi all,

I maintain a snap package for libreoffice¹, and it has been reported
that document files cannot be saved to $HOME/ ² because of the strict
confinement rules of snappy, whereby writing hidden files (filename
starting with a dot) in $HOME is forbidden.

I looked into the document file lock code, and came up with a simple
patch that removes the leading dot. So far, so good. It was pointed
out to me that file managers like Nautilus also consider files with a
trailing tilde (~) to be hidden, so I updated that patch so that lock
files are represented like so:

    $HOME/foobar.odt -> $HOME/foobar.odt.lock~

I was wondering about the trailing # in the current lock file
implementation. I dug into the git history, and it's always been there
as far as I can tell, but I'm not sure why. Can anyone shed some light
on this?
Is it safe to replace "#" with ".lock~" (only in the context of the
snap package, I don't intend to upstream that change unless it's
deemed sensible) ?

Cheers,

 Olivier

¹ https://snapcraft.io/libreoffice
² https://launchpad.net/bugs/1766192
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.