On 13.12.24 04:41, brian m. carlson wrote:
On 2024-12-12 at 09:14:50, Konrad Bucheli (PSI) wrote:
Dear git developers
Below my bug report:
What did you do before the bug happened? (Steps to reproduce your issue)
I do a `git init .` on a directory which is CIFS mounted via gio mount
(FUSE).
On RHEL8 this needs gvfs-smb and gvfs-fuse installed.
Mount command: gio mount smb://fs01.psi.ch/my_user_name$
In general, gvfs's FUSE driver isn't a good way to interact with files.
My experience with its SFTP driver is that it has a bunch of weird,
non-Unixy behaviour that's due to limitations in the gio interface. So
it probably doesn't provide the functionality most Unix programs will
expect from a file system, which will cause you a world of problems down
the line, as you've seen here.
True, but it has a big advantage: you can mount it without being root.
What did you expect to happen? (Expected behavior)
It initializes the git repo.
What happened instead? (Actual behavior)
$ git init .
error: chmod on /run/user/44951/gvfs/smb-share:server=fs01.psi.ch,share=my_user_name$/git/foo/.git/config.lock
failed: Operation not supported
fatal: could not set 'core.filemode' to 'false'
$
This is indeed the case, since the chmod on the config file fails. We
always rewrite the config file as a separate lock file, and then rename
into place. (This prevents concurrent modification correctly even on
network file systems.) The user generally wants the permissions to be
preserved, so this is the safe default.
This also happens when using a Linux Git on a WSL Windows mount.
Note that even Windows honours the read-only/read-write difference for
files, so in theory chmod is useful even on CIFS and other Windows file
systems.
If I remember correctly, the consensus last time this came up was that
someone is welcome to add a config option that ignores the chmod
failure, but that in general, we don't want to just silently ignore it.
Unfortunately, nobody has added such a configuration option yet.
My suggestion is not to silently ignore all chmod errors, only ENOTSUP
for config.lock which basically tells that it is not a suitable location
for that operation and thus also not required.
Would that be acceptable?
