<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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).</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you for consideration.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
[1] <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=115747" id="LPlnk913170">https://bugs.documentfoundation.org/show_bug.cgi?id=115747</a></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-- </div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best regards,</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Mike Kaganski.</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>¬°¬ä:</b> LibreOffice <libreoffice-bounces@lists.freedesktop.org> ¬à¬ä ¬Ú¬Þ¬Ö¬ß¬Ú Olivier Tilloy <olivier.tilloy@canonical.com><br>
<b>¬°¬ä¬á¬â¬Ñ¬Ó¬Ý¬Ö¬ß¬à:</b> 13 ¬Ú¬ð¬Ý¬ñ 2018 ¬Ô. 3:36<br>
<b>¬¬¬à¬Þ¬å:</b> libreoffice@lists.freedesktop.org<br>
<b>¬´¬Ö¬Þ¬Ñ:</b> leading dot and trailing # in lock files</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi all,<br>
<br>
I maintain a snap package for libreoffice©ö, and it has been reported<br>
that document files cannot be saved to $HOME/ ©÷ because of the strict<br>
confinement rules of snappy, whereby writing hidden files (filename<br>
starting with a dot) in $HOME is forbidden.<br>
<br>
I looked into the document file lock code, and came up with a simple<br>
patch that removes the leading dot. So far, so good. It was pointed<br>
out to me that file managers like Nautilus also consider files with a<br>
trailing tilde (~) to be hidden, so I updated that patch so that lock<br>
files are represented like so:<br>
<br>
    $HOME/foobar.odt -> $HOME/foobar.odt.lock~<br>
<br>
I was wondering about the trailing # in the current lock file<br>
implementation. I dug into the git history, and it's always been there<br>
as far as I can tell, but I'm not sure why. Can anyone shed some light<br>
on this?<br>
Is it safe to replace "#" with ".lock~" (only in the context of the<br>
snap package, I don't intend to upstream that change unless it's<br>
deemed sensible) ?<br>
<br>
Cheers,<br>
<br>
 Olivier<br>
<br>
©ö <a href="https://snapcraft.io/libreoffice">https://snapcraft.io/libreoffice</a><br>
©÷ <a href="https://launchpad.net/bugs/1766192">https://launchpad.net/bugs/1766192</a><br>
_______________________________________________<br>
LibreOffice mailing list<br>
LibreOffice@lists.freedesktop.org<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/libreoffice">https://lists.freedesktop.org/mailman/listinfo/libreoffice</a><br>
</div>
</span></font></div>
</body>
</html>