GNU bug report logs - #72641
31.0.50; "Unlocking file: Invalid argument" when deleting lock file on network file system

Previous Next

Full log

Message #8 received at 72641 <at> debbugs.gnu.org (full text, mbox):

From: Michal Nazarewicz <mina86 <at> mina86.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 72641 <at> debbugs.gnu.org
Subject: Re: 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

>> From: Michal Nazarewicz <mina86 <at> 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»

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.