---- El Fri, 20 Sep 2024 17:51:57 +0200, brian m. carlson escribió ---- > 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'm not sure why atomicity would be an issue here? The file already exists between the open and the fchmod, so another concurrent thread would be unable to open it regardless due to O_EXCL and O_CREAT. In fact, Git is *already* using this method of opening with 0600 for writing and then chmoding to 0444 when writing pack files: in builtin/index-pack.c, method open_pack_file opens with 0600 to write, and then chmods to 444 in rename_tmp_packfile. > Other folks may feel differently about fixing this, but I would suggest > against it. I understand that it's a workaround required due to non-POSIX compliance, but considering it should have no impact on any other OS and will actually as you said make buggy NFS mount work, IMHO it'd be still nice to have the changes made. ---- El Fri, 20 Sep 2024 20:15:42 +0200, Junio C Hamano escribió ---- > It depends on how hard it would be for filesystem providers to fix > their ware, but (1) leaving our code to require open semantics of > POSIX may serve as an incentive to encourage them to do so, and (2) > I am not fundamentally opposed to have an option to help users of > such flawed filesystem, provided if such a change is done cleanly. You mean adding a Git setting to, for example, disable using 444 mode altogether? Or do it in two steps (open + fchmod)?
