bug#23033: 24.5; Lock file uses the same extension as the file it's locking

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Michael Sloan]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

Lockfiles help the circumstance where multiple emacs processes are
editing the same file. The lockfile for 'File.hs' gets the name
'.#File.hs'.  This means that naive enumeration of all the files in the
directory with the extension '.hs' will also yield the lockfile.  Many
tools have behaviors that rely on enumerating all of the files which
have a particular extension, reasonably assuming that the user put them
there.

In particular, for me this caused the following issue:
https://github.com/commercialhaskell/stack/issues/1897

It seems wrong up for emacs to be writing files that have the extension
'.cabal' that are not cabal files. Even if they are named pipes that start
with '.', this causes problems for tools that expect files to be what their
name says they are.

Contrast this with backup files, which append a tilda to the end of the
filepath.  This changes the extension, and so tools don't get confused
by the extra files.

Version info:

In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
 of 2015-09-10 on computer
Repository revision: 866501efe0fdc0c29448e0aaf8696eb0a3c8fcd6

-Michael

[-- Attachment #2: Type: text/html, Size: 1569 bytes --]

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Glenn Morris]

Michael Sloan wrote:

> Lockfiles help the circumstance where multiple emacs processes are
> editing the same file. The lockfile for 'File.hs' gets the name
> '.#File.hs'.  This means that naive enumeration of all the files in the
> directory with the extension '.hs' will also yield the lockfile.  Many
> tools have behaviors that rely on enumerating all of the files which
> have a particular extension, reasonably assuming that the user put them
> there.

It's very long-standing behaviour.
So that we can assess how big the issue is, can you give some examples
of the tools that have issues with this?
As you say, it seems naive for a tool to simply find all files with a
given extension, including dotfiles that are non-existent symlinks.

> In particular, for me this caused the following issue:
> https://github.com/commercialhaskell/stack/issues/1897

Which you fixed the same day in the tool in question, right?

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Glenn Morris <rgm@gnu.org> writes:

> Michael Sloan wrote:
>
>> Lockfiles help the circumstance where multiple emacs processes are
>> editing the same file. The lockfile for 'File.hs' gets the name
>> '.#File.hs'.  This means that naive enumeration of all the files in the
>> directory with the extension '.hs' will also yield the lockfile.  Many
>> tools have behaviors that rely on enumerating all of the files which
>> have a particular extension, reasonably assuming that the user put them
>> there.
>
> It's very long-standing behaviour.
> So that we can assess how big the issue is, can you give some examples
> of the tools that have issues with this?
> As you say, it seems naive for a tool to simply find all files with a
> given extension, including dotfiles that are non-existent symlinks.
>
>> In particular, for me this caused the following issue:
>> https://github.com/commercialhaskell/stack/issues/1897
>
> Which you fixed the same day in the tool in question, right?

As much as I agree with the general sentiment above, one could also
consider users who are running e.g. 'find -iname "*.hs"' and are not
necessarily interested in seeing Emacs lock files.  IOW, if this is
not a big change, it could be worth doing it.  But it is mostly
cosmetic.

Best regards,
Stefan Kangas

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Michael Sloan]

[-- Attachment #1: Type: text/plain, Size: 2711 bytes --]

Correct, it is easy to fix in the tens of thousands of places where it can
cause misbehavior :)  But it is probably easier to fix it one place.

Here are some example issues I found searching for "emacs lockfile glob"
yields 22 results -
https://github.com/search?q=emacs+lockfile+glob&type=Issues - here are some
relevant ones:

* https://github.com/joeyespo/pytest-watch/issues/68
* https://github.com/joeyespo/pytest-watch/pull/101
* https://github.com/broccolijs/broccoli/issues/233
* https://github.com/michaelwayman/node-sass-chokidar/issues/24
* https://github.com/lammps/lammps/issues/1111

Searching for emacs "lockfile" yields 733 results -
https://github.com/search?q=emacs+"lockfile"&type=Issues
<https://github.com/search?q=emacs+%22lockfile%22&type=Issues> - here are
some relevant ones:

* https://github.com/microsoft/TypeScript/issues/29461
* https://github.com/jekyll/jekyll/issues/7888
* https://github.com/lukaszb/nose-watch/issues/15
* https://github.com/pylint-bot/pylint-unofficial/issues/367
* https://github.com/michaelwayman/node-sass-chokidar/issues/74
* https://github.com/karun012/arion/issues/30
* https://github.com/ananthakumaran/tide/issues/320

It is common to list files by extension.  I'm sure that this is just the
tip of the iceberg.

-Michael

On Thu, Nov 7, 2019 at 10:00 PM Stefan Kangas <stefan@marxist.se> wrote:

> Glenn Morris <rgm@gnu.org> writes:
>
> > Michael Sloan wrote:
> >
> >> Lockfiles help the circumstance where multiple emacs processes are
> >> editing the same file. The lockfile for 'File.hs' gets the name
> >> '.#File.hs'.  This means that naive enumeration of all the files in the
> >> directory with the extension '.hs' will also yield the lockfile.  Many
> >> tools have behaviors that rely on enumerating all of the files which
> >> have a particular extension, reasonably assuming that the user put them
> >> there.
> >
> > It's very long-standing behaviour.
> > So that we can assess how big the issue is, can you give some examples
> > of the tools that have issues with this?
> > As you say, it seems naive for a tool to simply find all files with a
> > given extension, including dotfiles that are non-existent symlinks.
> >
> >> In particular, for me this caused the following issue:
> >> https://github.com/commercialhaskell/stack/issues/1897
> >
> > Which you fixed the same day in the tool in question, right?
>
> As much as I agree with the general sentiment above, one could also
> consider users who are running e.g. 'find -iname "*.hs"' and are not
> necessarily interested in seeing Emacs lock files.  IOW, if this is
> not a big change, it could be worth doing it.  But it is mostly
> cosmetic.
>
> Best regards,
> Stefan Kangas
>

[-- Attachment #2: Type: text/html, Size: 4465 bytes --]

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Eli Zaretskii]

> From: Michael Sloan <mgsloan@gmail.com>
> Date: Thu, 7 Nov 2019 23:17:16 -0700
> Cc: 23033@debbugs.gnu.org
> 
> Correct, it is easy to fix in the tens of thousands of places where it can cause misbehavior :)  But it is probably
> easier to fix it one place.

Easier for whom?

These tools all have bugs: they choke on symlinks that point to
non-existent targets.  There could be symlinks like that which have
nothing to do with Emacs's lock files.  So from my POV we did those
tools a favor by exposing their bugs ;-)  I see no reason to sweep
the bugs of those packages under the carpet so as to make it easier
for their developers to keep those bugs.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Sloan <mgsloan@gmail.com>
>> Date: Thu, 7 Nov 2019 23:17:16 -0700
>> Cc: 23033@debbugs.gnu.org
>> 
>> Correct, it is easy to fix in the tens of thousands of places where it can cause misbehavior :)  But it is probably
>> easier to fix it one place.
>
> Easier for whom?

For humanity, taken as a whole, I think.  :-)

> These tools all have bugs: they choke on symlinks that point to
> non-existent targets.  There could be symlinks like that which have
> nothing to do with Emacs's lock files.  So from my POV we did those
> tools a favor by exposing their bugs ;-)  I see no reason to sweep
> the bugs of those packages under the carpet so as to make it easier
> for their developers to keep those bugs.

I agree with the general sentiment, but consider the amount of bugs
that Michael linked where the name "emacs" crops up.  Appearances
matters, to a certain extent.  To my mind it would be preferable, in
general, if we could avoid having a bunch of bug reports (because of
someone elses sloppiness in this case, yes) where it initially and
incorrectly may look like the culprit is "Emacs and its backwards
practices".

More importantly, I think, is what I mentioned before: this could
inconvenience users trying to run stuff using "find -iname '*.c'" and
the like, only to run into emacs lock files.  I do expect the tools
above to get their house in order and just Fix Their Bugs, but random
users doing one-offs is a different question.

That said, I don't feel super strongly about this.  I consider it a
minor cosmetic blemish.

Best regards,
Stefan Kangas

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Cc: Michael Sloan <mgsloan@gmail.com>,  23033@debbugs.gnu.org
> Date: Fri, 08 Nov 2019 15:03:55 +0100
> 
> I agree with the general sentiment, but consider the amount of bugs
> that Michael linked where the name "emacs" crops up.  Appearances
> matters, to a certain extent.  To my mind it would be preferable, in
> general, if we could avoid having a bunch of bug reports (because of
> someone elses sloppiness in this case, yes) where it initially and
> incorrectly may look like the culprit is "Emacs and its backwards
> practices".

Once again, this discussion is quite academic unless someone proposes
a specific change to consider.

Thanks.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 08 Nov 2019 06:00:14 +0100
> Cc: 23033@debbugs.gnu.org, Michael Sloan <mgsloan@gmail.com>
> 
> As much as I agree with the general sentiment above, one could also
> consider users who are running e.g. 'find -iname "*.hs"' and are not
> necessarily interested in seeing Emacs lock files.  IOW, if this is
> not a big change, it could be worth doing it.

What change did you have in mind?  AFAICT, no specific change was
proposed in that bug report.

The advantage of the current method is that Dired and 'ls' display the
lock file right near the file that is locked, at least on most systems
and with the default file sorting order.  If the change proposal will
order them far apart, it would be a disadvantage.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefan@marxist.se>
>> Date: Fri, 08 Nov 2019 06:00:14 +0100
>> Cc: 23033@debbugs.gnu.org, Michael Sloan <mgsloan@gmail.com>
>> 
>> As much as I agree with the general sentiment above, one could also
>> consider users who are running e.g. 'find -iname "*.hs"' and are not
>> necessarily interested in seeing Emacs lock files.  IOW, if this is
>> not a big change, it could be worth doing it.
>
> What change did you have in mind?  AFAICT, no specific change was
> proposed in that bug report.
>
> The advantage of the current method is that Dired and 'ls' display the
> lock file right near the file that is locked, at least on most systems
> and with the default file sorting order.  If the change proposal will
> order them far apart, it would be a disadvantage.

My suggestion would be to add a one character suffix to the file name.
For example ".", so that:

lrwxrwxrwx  1 skangas skangas     30 2019-11-08 15:06 .#package.el -> skangas@joffe.31542:1572461517

Would instead look like:

lrwxrwxrwx  1 skangas skangas     30 2019-11-08 15:06 .#package.el. -> skangas@joffe.31542:1572461517

That, I think, looks visually not too busy.

(The most clear would be a suffix "-emacs-lock" or "-lock" but that is
probably too ugly and long.)

Best regards,
Stefan Kangas

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Cc: rgm@gnu.org,  23033@debbugs.gnu.org,  mgsloan@gmail.com
> Date: Fri, 08 Nov 2019 15:10:50 +0100
> 
> My suggestion would be to add a one character suffix to the file name.
> For example "."

This isn't portable enough, it won't work on MS-Windows, where an
empty extension is "normalized" by the file-name APIs in a way that
removes the last dot, so you get the file name without the last dot.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Michael Sloan]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Fri, Nov 8, 2019 at 6:10 AM Stefan Kangas <stefan@marxist.se> wrote:

> (The most clear would be a suffix "-emacs-lock" or "-lock" but that is
> probably too ugly and long.)
>

Appending `.lock` seems fine to me (note the period rather than hyphen).  I
don't find it ugly, instead explanatory!  If users do see these file names,
then it is clearer that they are lock files.  There is precedent for use of
this file extension[0], and there's also lots of precedent for stacking
file extensions.

I propose keeping the traditional `.#` prefix but adding a `.lock` suffix.

[0]: https://fileinfo.com/extension/lock

[-- Attachment #2: Type: text/html, Size: 1013 bytes --]

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Eli Zaretskii]

> From: Michael Sloan <mgsloan@gmail.com>
> Date: Fri, 8 Nov 2019 22:17:29 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>, Glenn Morris <rgm@gnu.org>, 23033@debbugs.gnu.org
> 
> Appending `.lock` seems fine to me (note the period rather than hyphen).  I don't find it ugly, instead
> explanatory!  If users do see these file names, then it is clearer that they are lock files.  There is precedent for
> use of this file extension[0], and there's also lots of precedent for stacking file extensions.
> 
> I propose keeping the traditional `.#` prefix but adding a `.lock` suffix.

I think we should only consider adding punctuation characters, because
that would ensure these lock files are displayed right next to the
files they lock, like today.  Moving the lock files away of the files
they lock in the directory listing would be a disadvantage, IMO.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> > I propose keeping the traditional `.#` prefix but adding a `.lock` suffix.

OK, if that works on Windows it's better than what I proposed.

> I think we should only consider adding punctuation characters, because
> that would ensure these lock files are displayed right next to the
> files they lock, like today.  Moving the lock files away of the files
> they lock in the directory listing would be a disadvantage, IMO.

On this MacOS machine, I see the following:

$ ls -al
total 8
drwxr-xr-x  11 skangas  staff   352 Nov  9 10:05 .
lrwxr-xr-x   1 skangas  staff    33 Nov  9 10:05 .#foo ->
skangas@example.org.795
drwxr-xr-x  50 skangas  staff  1600 Nov  9 10:03 ..
-rw-r--r--   1 skangas  staff     0 Nov  9 10:03 a
-rw-r--r--   1 skangas  staff     0 Nov  9 10:03 e
-rw-r--r--   1 skangas  staff     3 Nov  9 10:05 foo
-rw-r--r--   1 skangas  staff     0 Nov  9 10:03 i
-rw-r--r--   1 skangas  staff     0 Nov  9 10:03 z

In other words, the lock file is not next to the file it locks.  Are
you seeing something else?

How would the ordering differ with a suffix like ".lock" compared to
"#" or some other punctuation character?  I would have thought that it
would be very similar.  Maybe I'm missing something.

Best regards,
Stefan Kangas

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 9 Nov 2019 10:12:11 +0100
> Cc: Michael Sloan <mgsloan@gmail.com>, Glenn Morris <rgm@gnu.org>, 23033@debbugs.gnu.org
> 
> > I think we should only consider adding punctuation characters, because
> > that would ensure these lock files are displayed right next to the
> > files they lock, like today.  Moving the lock files away of the files
> > they lock in the directory listing would be a disadvantage, IMO.
> 
> On this MacOS machine, I see the following:
> 
> $ ls -al
> total 8
> drwxr-xr-x  11 skangas  staff   352 Nov  9 10:05 .
> lrwxr-xr-x   1 skangas  staff    33 Nov  9 10:05 .#foo ->
> skangas@example.org.795
> drwxr-xr-x  50 skangas  staff  1600 Nov  9 10:03 ..
> -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 a
> -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 e
> -rw-r--r--   1 skangas  staff     3 Nov  9 10:05 foo
> -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 i
> -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 z
> 
> In other words, the lock file is not next to the file it locks.  Are
> you seeing something else?

Yes.

Is the above Gnu 'ls'?  And what is your locale?

> How would the ordering differ with a suffix like ".lock" compared to
> "#" or some other punctuation character?  I would have thought that it
> would be very similar.  Maybe I'm missing something.

The default file sort order in UTF-8 locales ignores punctuation
characters.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Michael Sloan]

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

Since sort order is lexicographic, lock files with ".lock" appended will
still typically be next to the files when listed.  The only exception I can
think of is if there are other related files with the same base name,
perhaps with a different stacked extension or suffix (like ~)

It is not the case that the current lock file names are always listed next
to the files they are clocking:

mgsloan@treetop:~/test$ ls -la

total 8

drwxrwxr-x  2 mgsloan mgsloan 4096 Nov  9 16:36  .

drwxr-xr-x 57 mgsloan mgsloan 4096 Nov  9 16:35  ..
-rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:36  .#test.md
-rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:36 '#.test.md'
-rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:35  test.md

On Sat, Nov 9, 2019 at 2:24 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Sat, 9 Nov 2019 10:12:11 +0100
> > Cc: Michael Sloan <mgsloan@gmail.com>, Glenn Morris <rgm@gnu.org>,
> 23033@debbugs.gnu.org
> >
> > > I think we should only consider adding punctuation characters, because
> > > that would ensure these lock files are displayed right next to the
> > > files they lock, like today.  Moving the lock files away of the files
> > > they lock in the directory listing would be a disadvantage, IMO.
> >
> > On this MacOS machine, I see the following:
> >
> > $ ls -al
> > total 8
> > drwxr-xr-x  11 skangas  staff   352 Nov  9 10:05 .
> > lrwxr-xr-x   1 skangas  staff    33 Nov  9 10:05 .#foo ->
> > skangas@example.org.795
> > drwxr-xr-x  50 skangas  staff  1600 Nov  9 10:03 ..
> > -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 a
> > -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 e
> > -rw-r--r--   1 skangas  staff     3 Nov  9 10:05 foo
> > -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 i
> > -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 z
> >
> > In other words, the lock file is not next to the file it locks.  Are
> > you seeing something else?
>
> Yes.
>
> Is the above Gnu 'ls'?  And what is your locale?
>
> > How would the ordering differ with a suffix like ".lock" compared to
> > "#" or some other punctuation character?  I would have thought that it
> > would be very similar.  Maybe I'm missing something.
>
> The default file sort order in UTF-8 locales ignores punctuation
> characters.
>

[-- Attachment #2: Type: text/html, Size: 3660 bytes --]

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Eli Zaretskii]

> From: Michael Sloan <mgsloan@gmail.com>
> Date: Sat, 9 Nov 2019 16:37:45 -0700
> Cc: Stefan Kangas <stefan@marxist.se>, Glenn Morris <rgm@gnu.org>, 23033@debbugs.gnu.org
> 
> Since sort order is lexicographic, lock files with ".lock" appended will still typically be next to the files when
> listed.

The sort order is not exactly lexicographic, because it ignores some
characters when comparing strings.

> It is not the case that the current lock file names are always listed next to the files they are clocking:
> 
> mgsloan@treetop:~/test$ ls -la                                                                                                       
> total 8                                                                                                                              
> drwxrwxr-x  2 mgsloan mgsloan 4096 Nov  9 16:36  .                                                                                   
> drwxr-xr-x 57 mgsloan mgsloan 4096 Nov  9 16:35  ..
> -rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:36  .#test.md
> -rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:36 '#.test.md'
> -rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:35  test.md

I agree that it is easy to cook an example where this doesn't happen,
but usually it does.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Michael Sloan]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Thu, Nov 14, 2019 at 2:18 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > It is not the case that the current lock file names are always listed
> next to the files they are clocking:
> >
> > mgsloan@treetop:~/test$ ls -la
>
> > total 8
>
> > drwxrwxr-x  2 mgsloan mgsloan 4096 Nov  9 16:36  .
>
> > drwxr-xr-x 57 mgsloan mgsloan 4096 Nov  9 16:35  ..
> > -rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:36  .#test.md
> > -rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:36 '#.test.md'
> > -rw-rw-r--  1 mgsloan mgsloan    0 Nov  9 16:35  test.md
>
> I agree that it is easy to cook an example where this doesn't happen,
> but usually it does.
>

Indeed!  And appending ".lock" to a file name is also typically adjacent in
listings, and it is easy to cook an example where it is not.

[-- Attachment #2: Type: text/html, Size: 1612 bytes --]

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefan@marxist.se>
>> Date: Sat, 9 Nov 2019 10:12:11 +0100
>> Cc: Michael Sloan <mgsloan@gmail.com>, Glenn Morris <rgm@gnu.org>, 23033@debbugs.gnu.org
>>
>> > I think we should only consider adding punctuation characters, because
>> > that would ensure these lock files are displayed right next to the
>> > files they lock, like today.  Moving the lock files away of the files
>> > they lock in the directory listing would be a disadvantage, IMO.
>>
>> On this MacOS machine, I see the following:
>>
>> $ ls -al
>> total 8
>> drwxr-xr-x  11 skangas  staff   352 Nov  9 10:05 .
>> lrwxr-xr-x   1 skangas  staff    33 Nov  9 10:05 .#foo ->
>> skangas@example.org.795
>> drwxr-xr-x  50 skangas  staff  1600 Nov  9 10:03 ..
>> -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 a
>> -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 e
>> -rw-r--r--   1 skangas  staff     3 Nov  9 10:05 foo
>> -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 i
>> -rw-r--r--   1 skangas  staff     0 Nov  9 10:03 z
>>
>> In other words, the lock file is not next to the file it locks.  Are
>> you seeing something else?
>
> Yes.
>
> Is the above Gnu 'ls'?  And what is your locale?

I see this in the macOS ls and the GNU ls with LC_COLLATE=C.

With `LC_COLLATE=en_US.UTF.8 ls -al`, I see that:

lrwxrwxrwx 1 skangas skangas     32 2021-09-25 01:54  .#foo ->
skangas@joffe.1358372:1630641938
-rw-r--r-- 1 skangas skangas      4 2021-09-25 01:54  foo

>> How would the ordering differ with a suffix like ".lock" compared to
>> "#" or some other punctuation character?  I would have thought that it
>> would be very similar.  Maybe I'm missing something.
>
> The default file sort order in UTF-8 locales ignores punctuation
> characters.

So how about using ".#foo#" instead of ".#foo"?

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> The default file sort order in UTF-8 locales ignores punctuation
>> characters.
>
> So how about using ".#foo#" instead of ".#foo"?

Is there any reason we don't just call these files .#foo.lock" or
something?  Putting "lock" into the name would make it clearer to the
users what these things are.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Is there any reason we don't just call these files .#foo.lock" or
> something?  Putting "lock" into the name would make it clearer to the
> users what these things are.

See below what Eli wrote earlier in this thread.

Eli Zaretskii <eliz@gnu.org> writes:

> I think we should only consider adding punctuation characters, because
> that would ensure these lock files are displayed right next to the
> files they lock, like today.  Moving the lock files away of the files
> they lock in the directory listing would be a disadvantage, IMO.

I use LC_COLLATE=C, so I have never had these files next to each other,
and never missed that feature either.

I also note that even with ".lock" the files are fairly close together,
and they are also colored differently so they stand out.

So from my perspective having the explanation ".lock" visible in the
name is worth more than a slightly better sort order.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> I think we should only consider adding punctuation characters, because
>> that would ensure these lock files are displayed right next to the
>> files they lock, like today.  Moving the lock files away of the files
>> they lock in the directory listing would be a disadvantage, IMO.
>
> I use LC_COLLATE=C, so I have never had these files next to each other,
> and never missed that feature either.

Yeah, they've never displayed close to each other for me, either.

> I also note that even with ".lock" the files are fairly close together,
> and they are also colored differently so they stand out.
>
> So from my perspective having the explanation ".lock" visible in the
> name is worth more than a slightly better sort order.

But would adding .lock to them change the sort order much?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I also note that even with ".lock" the files are fairly close together,
>> and they are also colored differently so they stand out.
>>
>> So from my perspective having the explanation ".lock" visible in the
>> name is worth more than a slightly better sort order.
>
> But would adding .lock to them change the sort order much?

Much?  I'd say no.  It changes a little, in most cases, e.g.:

-rw-r--r-- 1 skangas skangas      0 2021-09-25 02:02 .#foo#
-rw-r--r-- 1 skangas skangas     19 2021-09-25 03:33 foo
-rw-r--r-- 1 skangas skangas      0 2021-09-25 02:02 foob
-rw-r--r-- 1 skangas skangas      0 2021-09-25 02:01 foobar
-rw-r--r-- 1 skangas skangas      0 2021-09-25 02:00 .#foo.lock

I guess this starts to matter more when you have a ton of files named
fooXXX.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Much?  I'd say no.  It changes a little, in most cases, e.g.:
>
> -rw-r--r-- 1 skangas skangas      0 2021-09-25 02:02 .#foo#
> -rw-r--r-- 1 skangas skangas     19 2021-09-25 03:33 foo
> -rw-r--r-- 1 skangas skangas      0 2021-09-25 02:02 foob
> -rw-r--r-- 1 skangas skangas      0 2021-09-25 02:01 foobar
> -rw-r--r-- 1 skangas skangas      0 2021-09-25 02:00 .#foo.lock
>
> I guess this starts to matter more when you have a ton of files named
> fooXXX.

Ah, I see.  Well, perhaps adding a "#" at the end is the best fix here,
then, although it looks rather similar to the #auto-save# files then,
which might confuse people...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> Much?  I'd say no.  It changes a little, in most cases, e.g.:
>>
>> -rw-r--r-- 1 skangas skangas      0 2021-09-25 02:02 .#foo#
>> -rw-r--r-- 1 skangas skangas     19 2021-09-25 03:33 foo
>> -rw-r--r-- 1 skangas skangas      0 2021-09-25 02:02 foob
>> -rw-r--r-- 1 skangas skangas      0 2021-09-25 02:01 foobar
>> -rw-r--r-- 1 skangas skangas      0 2021-09-25 02:00 .#foo.lock
>>
>> I guess this starts to matter more when you have a ton of files named
>> fooXXX.
>
> Ah, I see.  Well, perhaps adding a "#" at the end is the best fix here,
> then,

I'm not convinced that ls ordering (under some locales) is the most
important concern.

I don't even understand why you would need to see that file.  It almost
seems better to not see it at all, or keeping it outside of the
directory, given that we have many other things in place to help the
user notice and deal with file locking and conflicts.

> although it looks rather similar to the #auto-save# files then,
> which might confuse people...

That's a good point.

I just checked some other editors:

- vim uses ".foo.swp"
- nano uses ".foo.swp"
- VSCode has no swap file (or it's not in the directory)
- GEdit has no swap file (or it's not in the directory)

Just to give a rough idea of what's considered acceptable out there.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I don't even understand why you would need to see that file.  It almost
> seems better to not see it at all, or keeping it outside of the
> directory, given that we have many other things in place to help the
> user notice and deal with file locking and conflicts.

I've started using lock-file-name-transforms myself to put the lock
files somewhere else, but most people will use the defaults here, and if
we want to change anything here, I think we have to tread carefully.
That is, if we introduce a change that makes things sort differently, we
should have a really good reason to do that, because it will annoy
(some) users.

So perhaps adding a "#" (or some other non-alphabetic character) at the
end is the solution that will have the least friction?  Are there any
other characters we could be using?  %?

> I just checked some other editors:
>
> - vim uses ".foo.swp"
> - nano uses ".foo.swp"
> - VSCode has no swap file (or it's not in the directory)
> - GEdit has no swap file (or it's not in the directory)

And these swap files serve the same purpose as our lock files?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I just checked some other editors:
>>
>> - vim uses ".foo.swp"
>> - nano uses ".foo.swp"
>> - VSCode has no swap file (or it's not in the directory)
>> - GEdit has no swap file (or it's not in the directory)
>
> And these swap files serve the same purpose as our lock files?

No idea.  They are created when I start editing a file.

I guess for a casual user the effect is the same, because all they will
notice is what I did: a file pops up when you start editing.

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> And these swap files serve the same purpose as our lock files?
>
> No idea.  They are created when I start editing a file.

Perhaps they're combined auto-save and lock files?  

> I guess for a casual user the effect is the same, because all they will
> notice is what I did: a file pops up when you start editing.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>>> And these swap files serve the same purpose as our lock files?
>>
>> No idea.  They are created when I start editing a file.
>
> Perhaps they're combined auto-save and lock files?

Something like that would be my guess.  The name ".swp" suggests it's
got more to do with auto-saving.

But come to think of it, would it be possible for us to use one combined
file?

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 26 Sep 2021 00:17:24 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, rgm@gnu.org, 23033@debbugs.gnu.org, mgsloan@gmail.com
> 
> > Perhaps they're combined auto-save and lock files?
> 
> Something like that would be my guess.  The name ".swp" suggests it's
> got more to do with auto-saving.
> 
> But come to think of it, would it be possible for us to use one combined
> file?

That'd complicate Emacs in non-trivial ways.  Currently, the auto-save
file is just a snapshot of the file's buffer, and the lock file is a
specialized file whose content tells us who and when locked it.  To
put both of these in the same file would mean the file will need
parsing.  Does it really make sense to do that?

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Andreas Schwab]

On Sep 26 2021, Eli Zaretskii wrote:

>> From: Stefan Kangas <stefan@marxist.se>
>> Date: Sun, 26 Sep 2021 00:17:24 -0700
>> Cc: Eli Zaretskii <eliz@gnu.org>, rgm@gnu.org, 23033@debbugs.gnu.org, mgsloan@gmail.com
>> 
>> > Perhaps they're combined auto-save and lock files?
>> 
>> Something like that would be my guess.  The name ".swp" suggests it's
>> got more to do with auto-saving.
>> 
>> But come to think of it, would it be possible for us to use one combined
>> file?
>
> That'd complicate Emacs in non-trivial ways.  Currently, the auto-save
> file is just a snapshot of the file's buffer, and the lock file is a
> specialized file whose content tells us who and when locked it.  To
> put both of these in the same file would mean the file will need
> parsing.  Does it really make sense to do that?

There is also auto-save-visited-mode, which would conflict with that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#23033: 24.5; Lock file uses the same extension as the file it's locking

[Lars Ingebrigtsen]

Re-skimming this thread lightly, I think the conclusion here was that
people that want different names should use `lock-file-name-transforms',
but changing the defaults would potentially be disruptive, since the
current behaviour is so long-standing (and user-visible).  So I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no