leading dot and trailing # in lock files

[olivier.tilloy@xxxxxxxxxxxxx (Olivier Tilloy)]

Hi Mike,

On Mon, Jul 16, 2018 at 8:00 AM Kaganski Mike <mikekaganski at hotmail.com> wrote:
>
> Hi Olivier,
>
> ________________________________
> Ð?Ñ?: Olivier Tilloy <olivier.tilloy at canonical.com>
> Ð?Ñ?пÑ?авлено: 14 иÑ?лÑ? 2018 г. 2:47
> Ð?омÑ?: mikekaganski at hotmail.com
> Ð?опиÑ?: libreoffice at lists.freedesktop.org
> Тема: Re: leading dot and trailing # in lock files
>
> Thanks Mike for the insights,
>
> My approach of changing the lock filename pattern was indeed naive and
> would invalidate the benefits of a cross-applications, cross-versions
> lock mechanism.
>
> There's little point in implementing an alternative pattern in cases
> where the regular lock file cannot be written, if this isn't
> propagated to other office programs and backported to all supported
> versions.
>
> Well - I don't agree. Actually, failing to do that would (1) disable our own current and future versions from taking advantages that lock files give: alternative locking where FS locking is unreliable/absent, and information about the party that had opened the document; and (2) disable other suites from catching up. There are cases where lock files aren't needed actually: e.g., WebDAV, where locking is handled by server in a different way. But for cases where such server-side locking and information is unavailable, I'd suggest still use alternative lockfile naming.
>
> Would it be possible instead to write the document itself
> and warn the user that no lock file could be written? Or does the
> absence of a lock file mean that the file can only be opened
> read-only?
>
> We could do this, but see above. Inability to write standard lockfile (when one is absent), while possibility to write lockfile with alternative name is a sure sign that we don't get caught to a situation when we will conflict with other suites, so we are good with the alternative naming. Why not doing that?

I guess that makes sense. So the next question is, which alternative
name pattern should we go for? We'd need to make sure that the
alternative pattern is valid across a broad range of
filesystems/locations, and ideally still appears as a hidden file in
most file managers.

Suggestions?

Thanks,

 Olivier