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 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/ce91ad92-598e-4b0a-90eb-662ba2841304o%40googlegroups.com.
