unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Eli Zaretskii <eliz@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>
Cc: 72641@debbugs.gnu.org
Subject: bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system
Date: Thu, 15 Aug 2024 19:44:16 +0200	[thread overview]
Message-ID: <+b8wcnteufggsda3gtf7ioja@mina86.com> (raw)
In-Reply-To: <86a5hd7o4t.fsf@gnu.org>

>> From: Michal Nazarewicz <mina86@mina86.com>
>> Date: Thu, 15 Aug 2024 17:41:03 +0200
>> 
>> I’m getting the same warning on Linux with Emacs 31.0.50 and it’s not
>> caused by a crash.
>> 
>>     emacs> M-x find-file RET /o/foo RET blah RET
>>     cli> $ ls -l /o/.#foo 
>>     cli> -rw------- 1 mpn mpn 0 2024-08-15 16:30 /o/.#foo
>>     emacs> M-x save-buffer RET
>>     emacs> ⛔ Warning (unlock-file): Unlocking file: Invalid argument, /o/foo, ignored
>>     cli> $ $ ls -l /o/.#foo /o/foo
>>     cli> -rw------- 1 mpn mpn 5 2024-08-15 16:31 /o/foo
>>     cli> -rw------- 1 mpn mpn 0 2024-08-15 16:30 /o/.#foo
>> 
>> The problem appears to be that /o is a network file-system which does
>> not support symbolic links:
>> 
>>     $ mount |grep /o
>>     //192.168.x.x/data on /o type cifs (rw,relatime,vers=3.0,cache=strict,username=mpn,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.x.x,file_mode=0600,dir_mode=0700,soft,nounix,serverino,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1,_netdev)
>>     $ ln -s /o/foo /o/f
>>     ln: failed to create symbolic link '/o/f': Input/output error
>> 
>> I guess Emacs notices that when it tries to create a lock file and falls
>> back to creating a file, but then it assumes it’s a symlink when trying
>> to remove it.

On Thu, Aug 15 2024, Eli Zaretskii wrote:
> I'm not sure we need to do anything here, either, but maybe Paul
> (CC'ed) has other suggestions or ideas.

The way I see it, Emacs has created those files so Emacs should clean
after itself.  Though I’ve looked at it a bit more closely and it’s
weirder than my original guess.

symlink(2) creates the file (as in it creates a regular file rather than
a symbolic link) and returns EIO.  create_lock_file reports an error and
does not go into its fallback.  This is why the lock file is empty.  In
the end, the error comes from current_lock_owner as it tries to parse
the empty file.

The *Warnings* buffer constantly popping up is annoying so I’d love this
to be addressed though to be honest I’m not sure what would be a good
solution.  Though I guess you can also argue this is CIFS bug.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»





  parent reply	other threads:[~2024-08-15 17:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-16  0:53 bug#70973: 29.1; "Unlocking file: Invalid argument" Warning saving via a softlink with stale file lock Duncan Greatwood
2024-05-16  8:43 ` Eli Zaretskii
2024-05-16 14:17   ` Duncan Greatwood
2024-05-16 15:46     ` Eli Zaretskii
2024-05-16 15:55       ` Duncan Greatwood
2024-05-16 16:09         ` Eli Zaretskii
2024-05-16 16:20           ` Duncan Greatwood
2024-05-16 18:18             ` Eli Zaretskii
2024-05-16 19:27               ` Duncan Greatwood
2024-05-16 19:51                 ` Eli Zaretskii
2024-05-16 21:36                   ` Duncan Greatwood
2024-06-01 14:04                     ` Eli Zaretskii
2024-08-15 15:59                   ` bug#72641: 31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system Michal Nazarewicz
     [not found]                   ` <2+lcnmedng9le3pwfn0gc79m@mina86.com>
     [not found]                     ` <86a5hd7o4t.fsf@gnu.org>
2024-08-15 17:44                       ` Michal Nazarewicz [this message]
2024-08-15 21:43                         ` Paul Eggert
2024-08-16  0:59                           ` Michal Nazarewicz
2024-08-16  3:20                             ` Paul Eggert
2024-08-17 20:03                               ` Michal Nazarewicz
2024-08-17 22:38                                 ` Paul Eggert
2024-08-17 22:55                                   ` Mike Kupfer
2024-08-17 23:08                                     ` Mike Kupfer
2024-08-18 21:15                                   ` Michal Nazarewicz
2024-08-18 21:25                                     ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=+b8wcnteufggsda3gtf7ioja@mina86.com \
    --to=mina86@mina86.com \
    --cc=72641@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).