From: Konrad Bucheli (PSI) Date: Fri, 13 Dec 2024 10:32:22 GMT Subject: Re: chmod failure on GVFS mounted CIFS share Message-ID: In-Reply-To: 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?