On 2024-09-20 at 22:39:51, Marcos Del Sol Vives wrote: > ---- El Fri, 20 Sep 2024 22:43:31 +0200, brian m. carlson escribió ---- > 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. I have been using Debian for many years and have contributed to several of the packages. I assure you that using what Git is doing is not, in fact, uncommon. It may be that you haven't run into it, but it is definitely not rare. For example, I just found an example of doing exactly the same thing in zsh, which is a major project that people use across distros. There's apparently another in the elm MUA. I found yet another one in some m4 (autoconf) files used in building Emacs. And there are a lot of other examples you can find by searching GitHub's code search for "open O_WRONLY 0444". Perhaps you don't use any of that software, but they're all substantial projects that are in common use across Linux distros and Unix systems in general. I am a zsh user, for instance. > > 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. I have actually answered questions about chmod failing to work in some cases on WSL, which causes operations to fail. Here's a different question on StackOverflow that demonstrates a particular problem that's common where chmod fails to work in Git on certain WSL drives[0]. The error looks like this: Cloning into '<repo>'... error: chmod on /mnt/c/Users/User/Code/<repo>/.git/config.lock failed: Operation not permitted fatal: could not set 'core.filemode' to 'false' If this situation occurs, your patch will actually leave the file writable, which we don't want, since the fchmod will silently fail. It may be that WSL has changed since that was written, but I've seen reports of that happening relatively recently, and, in any event, we don't want to require that people use the absolute latest WSL to get things working. Again, maybe Junio will accept a patch here, but I don't think the current one is going to work correctly, even on WSL. It may not be obvious that it's broken because the patch ignores fchmod's exit status. If you want to submit a patch that uses an option to either use the old behaviour or one that does an fchmod after the fact, that would probably be accepted, as long as you added tests (including the read-only bit) for both cases and sufficient documentation. [0] https://askubuntu.com/questions/1115564/wsl-ubuntu-distro-how-to-solve-operation-not-permitted-on-cloning-repository -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
