bug#37573: 27.0.50; Remote file opened from GNOME-Nautilus

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> I could reproduce it locally. The problem is, that /run/user/1000/gvfs/
>> is a GVFS mounted file system. Most of native file operations work
>> there, but there seems to be a problem to handle symlinks like .#filename
>> which are used to mark locked files.
>>
>> Saving the modified buffer itself works. So it might be appropriate to
>> suppress the file locking on GVFS mounted file systems. Add the
>> following lines to your .emacs:
>>
>> (put 'create-lockfiles 'safe-local-variable 'booleanp)
>> (dir-locals-set-class-variables 'gvfs '((nil . ((create-lockfiles . nil)))))
>> (dir-locals-set-directory-class (format "/run/user/%d/gvfs" (user-uid)) 
>> 'gvfs)
>>
>> I'm wondering, whether we shall document this approach somewhere. Eli?
>
> Does this file operation always fail on GVFS volumes?  If so, perhaps
> we should not create lockfiles on such volumes by default?

I've tested the scenario (editing a remote file from Nautilus via Emacs)
with GVFS volumes of different types. ftp and afp-volume work w/o
problems. ssh/sftp behaves as reported (problem with file locking).

dav(s), google-drive and smb-share give another error:

Error: (file-error "Doing chmod" "Operation not supported" 
"/run/user/1000/gvfs/smb-share:server=detlef,share=netlogon/tmp/tramp-test1H01tS")

So it doesn't make sense to implement the workaround in general. What we
could do instead is to map all files under "/run/user/%d/gvfs" to the
respective Tramp file name. Don't know whether it is worth the effort.

After all, I believe we shall simply document the behavior, and the
workaround for ssh/sftp.

Best regards, Michael.