Re: chmod failure on GVFS mounted CIFS share
- From
- Konrad Bucheli (PSI) <konrad.bucheli@psi.ch>
- Date
- Dec 13, 2024, 10:32 UTC
- Message-ID
- <c22a7d5e-cbfe-48a9-bdf5-e73f21ac648f@psi.ch>
- In-Reply-To
- <Z1us2FpyObVpJlsM@tapette.crustytoothpaste.net>
On 13.12.24 04:41, brian m. carlson wrote:
Show 19 quoted lines
> 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.
Show 28 quoted lines
>> 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?