Re: Permission issue in Git in DrvFs-mounted network drives
- From
- Marcos Del Sol Vives <marcos@orca.pet>
- Date
- Sep 20, 2024, 22:39 UTC
- Message-ID
- <1921197742f.d7b8c9992630384.1644253106538527208@orca.pet>
- In-Reply-To
- <Zu3ec1mDj9JD1Bbj@tapette.crustytoothpaste.net>
---- El Fri, 20 Sep 2024 22:43:31 +0200, brian m. carlson escribió ----
Show 7 quoted lines
> Git could, in theory, accept a patch here. However, you're also going > to have lots of other software that breaks in this case, not just Git. > So it's less useful to patch Git and hundreds of other packages on Linux > distributions that have relied on the POSIX standard and more useful to > fix your OS (or maybe switch to WSL2, if that doesn't have the problem). > Most Linux distros will generally not be interested in fixing this class > of problem, in my experience.
There is not a significant amount of software that opens files for writing in read-only mode. Despite using WSL extensively for development, so far Git has been the only that failed to work.
WSL2 has poor support for accessing local devices (such as serial ports, something really useful for embedded development like the Proxmark project where I contribute to) or pipes (which I use to sign commits using a TPM-backed SSH key), so it's not really an option.
Show 5 quoted lines
> In addition, chmod doesn't always work under WSL. I believe it _does_ > work if the drive is mounted with metadata, but some people don't have > that enabled and I don't know if it works for all drives. For those > people, the current code will work, since it doesn't call chmod or > fchmod, but it will fail with your patch.
I can guarantee you it'll work under WSL, even without metadata, because I've patched Git on my WSL1 Debian machine by doing the aforementioned trick and it totally works. Metadata is not even supported on anything but local NTFS drives.
WSL1, when mounted without metadata, chmod and fchmod calls will not fail but would instead just ignore the call, *except* when setting mode 444, 400 or any other read-only mode where it will set the FAT/NTFS read-only attribute:
marcos@desk:/mnt/nas/marcos$ mount | grep nas \\192.168.0.245\marcos on /mnt/nas/marcos type drvfs (rw,relatime,uid=1000,gid=1000,case=off) marcos@desk:/mnt/nas/marcos$ touch readonly marcos@desk:/mnt/nas/marcos$ ls -l readonly -rwxrwxrwx 1 marcos marcos 0 Sep 21 00:33 readonly marcos@desk:/mnt/nas/marcos$ chmod 444 readonly marcos@desk:/mnt/nas/marcos$ ls -l readonly -r-xr-xr-x 1 marcos marcos 0 Sep 21 00:33 readonly
That is exactly what is causing the issue - two SMB requests are being issued: one to create the file in read-only mode, and then another to open it.