On 2024-09-18 at 16:16:26, Marcos Del Sol Vives wrote: > Under WSL1 (Windows Subsystem for Linux), when using a network share > mounted via DrvFs, Git fails to add any files to a new or an existing > repository. > > The reason is that Git tries to open a temporary file as with RW > permissions but mode 0444, which causes WSL1 (or Samba, unsure who's here > to blame) to create first an file empty with the read-only DOS attribute set > that prevents any writes, and then actually trying to opening it in write > mode, which of course fails. > > Seems to be a pretty common issue that nobody has yet reported officially, > judging by the amount of posts on Stackoverflow, impacting not only WSL > but also CIFS under Linux (hence why sending to this mailing list and not > the Windows-specific one): > > - https://superuser.com/questions/681196/debugging-git-repo-permissions-on-samba-share > - https://superuser.com/questions/1450094/git-on-wsl-commands-fail-despite-permissions-seeming-fine > - https://superuser.com/questions/1491499/use-git-on-a-shared-drive-within-wsl > > As a workaround, opening the file with permissions 0600 and then using a > fchmod with the final desired mode works, which is a very small change that > should cause no issues under neither real Linux nor WSL: This behaviour also occurs on some broken NFS mounts. It is, however, explicitly permitted by POSIX to open a file 0444 with O_WRONLY or O_RDWR, and we've traditionally not fixed it for that reason. I would say that WSL1 behaviour is incorrect here. Here's what POSIX says[0]: The argument following the oflag argument does not affect whether the file is open for reading, writing, or for both. That is, POSIX forbids failing to open a file for writing because the permissions are 0444, and as such this is not POSIX compliant. Note that the operation must also be atomic; that is, the server can't emulate this by setting the permissions to 0600 and then doing an fchmod internally unless nobody can ever detect the intermediate state. I think we also probably have a few other codepaths that are affected in the same way and this is maybe just the most noticeable. Other folks may feel differently about fixing this, but I would suggest against it. > The WSL team at Microsoft has been already informed as well: > https://github.com/microsoft/WSL/issues/12051 I've provided some comments in the issue there. [0] https://pubs.opengroup.org/onlinepubs/9799919799/functions/open.html -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
