For anyone lurking or searching : the discussion is at https://lore.kernel.org/git/capx1gvfkxu8gwbp0gn2dbf9th874skkjd-echeafr7_77o8...@mail.gmail.com/T/#mead6be6c92f0ab29cf9fd600781dea7315e87411 with a reply confirming that the issue is the way posix permissions are mapped to NFS and that the particular posix permissions are a deliberate design feature in Git, so it's not going to change on that side of the FS.
Maybe needs an adapter/shim layer that can be enabled as an option for the .git directory? On Thursday, July 16, 2020 at 3:20:54 PM UTC+1, LTPCGO LTPCGO wrote: > > I THINK it might appear on certain virtual setups, and the problem seems > to be treated in a different way in G4W. I've posted to the mailing list > though and will continue discussion there...in plain text. I assumed your > 'no! HTML' wasn't a case of https://www.youtube.com/watch?v=5yuL6PcgSgM ! > > On Thursday, 16 July 2020 15:53:17 UTC+2, Philip Oakley wrote: >> >> Hi, >> >> I guess then that it's best to try for the g...@vger.kernel.org >> <javascript:> list. It needs to be pure plain text messages (no! HTML) >> with a clear explanation of the problem. >> >> Git's code generally assumes posix semantics, so the issues mentioned in >> the mergerfs thread about the linkage to the Windows NTFS semantics will >> need to be carefully teased out for the devs. To me it sounds like you need >> the posix assumptions to be guarded so that in the case mergerfs case the >> additional semantics of the mergerfs NTFS compatibility layer need to be >> accounted for. >> >> Have you looked at the Git-for-Windows compatibility layers? That code >> may have already 'solved' the problem, but is a different build with it's >> own patches. not sure how mergerfs would want to work 'out of the box' (Git >> & mergerfs) across the FS incompatibility. >> >> There is a current thread on an issue about the openat() (search the list >> archive) having an unexpected signal (SIG) which is pointing to perhaps an >> issue about the exact posix semantics, but that may be a red herring. >> >> Philip >> (I'm not that familiar with these parts of the system - hopefully I'm >> managing to link relevant folks together) >> >> On Thursday, July 16, 2020 at 1:45:14 AM UTC+1, LTPCGO LTPCGO wrote: >>> >>> It's on git distributed by Linux distros, but is most readily apparent >>> on systems using Windows Subsystem for Linux. It's also discussed at >>> length here: https://github.com/trapexit/mergerfs/issues/626 hence >>> posting to this community - is it better to open a discussion at the other >>> mailing list then? >>> >>> >>> >>> On Monday, 13 July 2020 13:00:37 UTC+2, Philip Oakley wrote: >>>> >>>> Is this for Linux, or Windows? Either way, it probably best to take up >>>> the discussions direct with the Dev community at either >>>> g...@vger.kernel.org (list archive https://lore.kernel.org/git/) or as >>>> a Git-for-Windows Issue ( >>>> https://github.com/git-for-windows/git/issues?q=is%3Aissue+), ideally >>>> as a PR (pull request) for discussion. >>>> >>>> Philip >>>> >>>> On Friday, July 10, 2020 at 1:29:55 PM UTC+1, LTPCGO LTPCGO wrote: >>>>> >>>>> On certain file systems, there are issues with staging a commit >>>>> because a call to open a file stored under .git/objects fails. It has >>>>> been >>>>> brought up in this discussion group previously. >>>>> >>>>> I have attached a fix below, but it would be much better to fix in the >>>>> code. I am curious first, before proposing a fix in the code (although I >>>>> can't find the specific call in the source at >>>>> https://github.com/git/git ), what the reasoning is for the current >>>>> permissions check on the call rather than checking the contents of the >>>>> opened tmp file. >>>>> >>>>> cc -Wall -O3 -D_GNU_SOURCE -fPIC -c -o githack.o githack.c; gcc -o >>>>> githack.so -nostartfiles -shared githack.o -ldl; >>>>> >>>>> >>>>> LD_PRELOAD=./githack.so git commit -a -m "Some new commit" >>>>> >>>>> >>>>> The code is below: >>>>> >>>>> #include <stdio.h> >>>>> #include <stdlib.h> >>>>> #include <string.h> >>>>> #include <sys/stat.h> >>>>> #include <sys/types.h> >>>>> //#define openat ignorethisopen >>>>> #define open ignorethisopen >>>>> #define open64 ignorethisopen64 >>>>> #include <fcntl.h> >>>>> //#undef openat >>>>> #undef open >>>>> #undef open64 >>>>> #include <dlfcn.h> >>>>> >>>>> /* >>>>> 'strace git ...' will show git fail on an openat() command >>>>> this is probably implemented as open64() on your system >>>>> you can confirm this by use of 'ltrace git ...' >>>>> you may also need to adjust the oflag comparison of 194 >>>>> */ >>>>> >>>>> /*static int (*___openat)(int, char *, int, mode_t);*/ >>>>> static int (*___open)(const char *, int, mode_t); >>>>> static int (*___open64)(const char *, int, mode_t); >>>>> >>>>> static void* dlwrap(const char *fn) >>>>> { >>>>> const char *e; >>>>> void *p = dlsym(RTLD_NEXT, fn); >>>>> if ((e=dlerror())!=0) fprintf(stderr, "dlsym(RTLD_NEXT,'%s'): >>>>> %s\r\n", fn, e); >>>>> return p; >>>>> } >>>>> >>>>> void _init(void) >>>>> { >>>>> ___open = dlwrap("open"); >>>>> ___open64 = dlwrap("open64"); >>>>> } >>>>> >>>>> /*int openat(int dirfd, const char *pathname, int oflag, mode_t mode)*/ >>>>> int open(const char *pathname, int oflag, mode_t mode) >>>>> { >>>>> if (oflag && oflag == 194) >>>>> return ___open(pathname, oflag, S_IRWXU); >>>>> return ___open(pathname, oflag, mode); >>>>> } >>>>> >>>>> int open64(const char *pathname, int oflag, mode_t mode) >>>>> { >>>>> if (oflag && oflag == 194) >>>>> return ___open64(pathname, oflag, S_IRWXU); >>>>> return ___open64(pathname, oflag, mode); >>>>> } >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/54b2a1de-73e8-4722-8a1d-ccec027ae625o%40googlegroups.com.
