{"thread":{"id":"9746","subject":"Stats in Git","startedAt":"2007-09-02T14:49:55Z","lastAt":"2007-09-07T06:36:08Z","messageCount":86,"participants":["Marius Storm-Olsen","Reece Dunn","Brian Gernhardt","Johannes Schindelin","David Kastrup","Johannes Sixt","Alex Riesen","Robin Rosenberg","Matthieu Moy","Miklos Vajna","Rutger Nijlunsing","Douglas Stockwell"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"52204","messageId":"46DACD93.9000509@trolltech.com","threadId":"9746","inReplyTo":null,"subject":"Stats in Git","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T14:49:55Z","receivedAt":"2007-09-02T14:49:55Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"I was checking out the performance situation with Git on Windows, and\nfound out that the Posix stat functions on Windows are just obscenely\nslow. We really can't use them, at least on in Git. So, I made a patch\nfor the MinGW version, which I'll post right after this mail.\n\nHowever, while look at that whole stat'ing situation in git, I saw\nthat doing 'git status' actually stats all the files _thrice_!\nYup, that's not 1 time, or 2 times, but actually 3(!) times before\n'git status' is content!\nI know that git-status is a script, so I think this clearly indicates\nthat git-status is a prime candidate for a built-in ;-)\n\nI haven't looked into details as to why it stats the files so many\ntimes. I guess someone more experienced in Git core could give an\nopinion, if by writing git-status as a builtin it would be possible to\nonly stat the files once. It would have a huge impact on Windows where\nstats are inheritly much slower than on Linux.\n\nBy applying the diff below, you can see for yourself what happens when\nyou stat the repo created with Moe's script:\n    mkdir bummer\n    cd bummer\n    for ((i=0;i<100;i++)); do\n    mkdir $i && pushd $i;\n    for ((j=0;j<1000;j++)); do\n    echo \"$j\" >$j; done; popd;\n    done\n\n$ git status 2>&1 | wc -l\n300137\n\nFast on Linux now, but still quite slow on Windows..\n\n--\n.marius\n\n\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex ca0a597..6b6405c 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -369,4 +369,23 @@ static inline int strtoul_ui(char const *s, int base, unsigned int *result)\n \treturn 0;\n }\n\n+static inline int git_lstat(const char *file_name, struct stat *buf)\n+{\n+\tfprintf(stderr, \"lstat: %s\\n\", file_name);\n+\treturn lstat(file_name, buf);\n+}\n+static inline int git_fstat(int fd, struct stat *buf)\n+{\n+\tfprintf(stderr, \"fstat: %d\\n\", fd);\n+\treturn fstat(fd, buf);\n+}\n+static inline int git_stat(const char *file_name, struct stat *buf)\n+{\n+\tfprintf(stderr, \"stat: %s\\n\", file_name);\n+\treturn stat(file_name, buf);\n+}\n+#define lstat(x,y) git_lstat(x,y)\n+#define fstat(x,y) git_fstat(x,y)\n+#define stat(x,y) git_stat(x,y)\n+\n #endif\n"},{"id":"52205","messageId":"46DACE0D.5070501@trolltech.com","threadId":"9746","inReplyTo":"46DACD93.9000509@trolltech.com","subject":"[PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T14:51:57Z","receivedAt":"2007-09-02T14:51:57Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"This gives us a significant speedup when adding, committing and stat'ing files.\n(Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n\nSigned-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>\n---\nThe following patch will override the normal Posix implementation of stat and\nlstat on Windows, and use normal Windows API to ensure we're stat'ing as fast\nas possible. With this patch I get the performance increase to the far right.\n\nInitially, I only replaced lstat, since that's what the MinGW port of Git had\nimplemented from before. But, since we don't really care about symlinks on\nWindows, I decided to simply use the same implementation for stat as well. The\nperformance benefit is clearly indicated in the report below.\n\n\n With normal lstat & stat   lstat, based on Win32      lstat & stat, as Win32\n -------------------------  -------------------------  -------------------------\n Command: git init          Command: git init          Command: git init\n -------------------------  -------------------------  -------------------------\n\n real    0m0.047s           real      0m0.047s         real       0m0.078s\n user    0m0.031s           user      0m0.031s         user       0m0.031s\n sys     0m0.000s           sys       0m0.000s         sys        0m0.000s\n\n -------------------------  -------------------------  -------------------------\n Command: git add .         Command: git add .         Command: git add .\n -------------------------  -------------------------  -------------------------\n\n real    0m19.390s          real      0m19.390s        real       0m12.187s\n user    0m0.015s           user      0m0.015s         user       0m0.015s\n sys     0m0.030s           sys       0m0.030s         sys        0m0.015s\n\n -------------------------  -------------------------  -------------------------\n Command: git commit -a...  Command: git commit -a...  Command: git commit -a...\n -------------------------  -------------------------  -------------------------\n\n real    0m30.812s          real      0m22.547s        real       0m17.297s\n user    0m0.015s           user      0m0.031s         user       0m0.015s\n sys     0m0.000s           sys       0m0.000s         sys        0m0.015s\n\n -------------------------  -------------------------  -------------------------\n 3x Command: git-status     3x Command: git-status     3x Command: git-status\n -------------------------  -------------------------  -------------------------\n\n real    0m11.860s          real      0m5.360s         real       0m5.344s\n user    0m0.015s           user      0m0.015s         user       0m0.015s\n sys     0m0.015s           sys       0m0.015s         sys        0m0.031s\n\n real    0m11.703s          real      0m5.312s         real       0m5.390s\n user    0m0.015s           user      0m0.015s         user       0m0.031s\n sys     0m0.000s           sys       0m0.000s         sys        0m0.000s\n\n real    0m11.672s          real      0m5.359s         real       0m5.344s\n user    0m0.031s           user      0m0.015s         user       0m0.015s\n sys     0m0.000s           sys       0m0.015s         sys        0m0.016s\n\n -------------------------  -------------------------  -------------------------\n Command: git commit...     Command: git commit...     Command: git commit...\n (single file)              (single file)              (single file)\n -------------------------  -------------------------  -------------------------\n\n real    0m14.234s          real      0m7.969s         real       0m7.875s\n user    0m0.015s           user      0m0.015s         user       0m0.015s\n sys     0m0.000s           sys       0m0.016s         sys        0m0.000s\n\n compat/mingw.c    |   52 ++++++++++++++++++++++++++++++++++++++++++++--------\n git-compat-util.h |    5 +++++\n 2 files changed, 49 insertions(+), 8 deletions(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 7711a3f..207378c 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -23,19 +23,52 @@ int fchmod(int fildes, mode_t mode)\n \treturn -1;\n }\n\n-int lstat(const char *file_name, struct stat *buf)\n+static inline time_t filetime_to_time_t(const FILETIME *ft)\n+{\n+\tlong long winTime = ((long long)ft->dwHighDateTime << 32) + ft->dwLowDateTime;\n+\twinTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */\n+\twinTime /= 10000000;\t\t /* Nano to seconds resolution */\n+\treturn (time_t)winTime;\n+}\n+\n+extern int _getdrive( void );\n+int git_lstat(const char *file_name, struct stat *buf)\n {\n \tint namelen;\n \tstatic char alt_name[PATH_MAX];\n-\n-\tif (!stat(file_name, buf))\n+\tchar* ext;\n+\tWIN32_FILE_ATTRIBUTE_DATA fdata;\n+\n+\tif (GetFileAttributesExA(file_name, GetFileExInfoStandard, &fdata)) {\n+\t\tint fMode = S_IREAD;\n+\t\tif (fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)\n+\t\t\tfMode |= S_IFDIR;\n+\t\telse {\n+\t\t\tfMode |= S_IFREG;\n+\t\text = strrchr(file_name, '.');\n+\t\tif (ext && (!_stricmp(ext, \".exe\") ||\n+\t\t\t    !_stricmp(ext, \".com\") ||\n+\t\t\t    !_stricmp(ext, \".bat\") ||\n+\t\t\t    !_stricmp(ext, \".cmd\")))\n+\t\t\tfMode |= S_IEXEC;\n+\t\t}\n+\t\tif (!(fdata.dwFileAttributes & FILE_ATTRIBUTE_READONLY))\n+\t\t\tfMode |= S_IWRITE;\n+\n+\t\tbuf->st_ino = 0;\n+\t\tbuf->st_gid = 0;\n+\t\tbuf->st_uid = 0;\n+\t\tbuf->st_nlink = 1;\n+\t\tbuf->st_mode = fMode;\n+\t\tbuf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since it's not a stat64 */\n+\t\tbuf->st_dev = buf->st_rdev = (_getdrive() - 1);\n+\t\tbuf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));\n+\t\tbuf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));\n+\t\tbuf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));\n \t\treturn 0;\n+\t}\n+\terrno = ENOENT;\n\n-\t/* if file_name ended in a '/', Windows returned ENOENT;\n-\t * try again without trailing slashes\n-\t */\n-\tif (errno != ENOENT)\n-\t\treturn -1;\n \tnamelen = strlen(file_name);\n \tif (namelen && file_name[namelen-1] != '/')\n \t\treturn -1;\n@@ -47,6 +80,9 @@ int lstat(const char *file_name, struct stat *buf)\n \talt_name[namelen] = 0;\n \treturn stat(alt_name, buf);\n }\n+int git_stat(const char *file_name, struct stat *buf) {\n+    return git_lstat(file_name, buf);\n+}\n\n /* missing: link, mkstemp, fchmod, getuid (?), gettimeofday */\n int socketpair(int d, int type, int protocol, int sv[2])\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 1ba499f..de1f062 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -488,6 +488,11 @@ int mingw_rename(const char*, const char*);\n extern void quote_argv(const char **dst, const char **src);\n extern const char *parse_interpreter(const char *cmd);\n\n+/* Make git on Windows use git_lstat and git_stat instead of lstat and stat */\n+int git_lstat(const char *file_name, struct stat *buf);\n+int git_stat(const char *file_name, struct stat *buf);\n+#define lstat(x,y) git_lstat(x,y)\n+#define stat(x,y) git_stat(x,y)\n #endif /* __MINGW32__ */\n\n #endif\n--\nmingw.v1.5.2.4.1311.g376df-dirty\n"},{"id":"52206","messageId":"46DACF57.3030603@trolltech.com","threadId":"9746","inReplyTo":"46DACE0D.5070501@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T14:57:27Z","receivedAt":"2007-09-02T14:57:27Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Sorry, should have added that this is a MinGW port patch only. And I\nforgot to include the msysgit mailinglist, nice..\n\n--\n.marius\n"},{"id":"52213","messageId":"3f4fd2640709020832x656fa78djf29117690318ea48@mail.gmail.com","threadId":"9746","inReplyTo":"46DACE0D.5070501@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2007-09-02T15:32:41Z","receivedAt":"2007-09-02T15:32:41Z","isPatch":true,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 02/09/07, Marius Storm-Olsen <marius@trolltech.com> wrote:\n> This gives us a significant speedup when adding, committing and stat'ing files.\n> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n>\n> +               if (ext && (!_stricmp(ext, \".exe\") ||\n> +                           !_stricmp(ext, \".com\") ||\n> +                           !_stricmp(ext, \".bat\") ||\n> +                           !_stricmp(ext, \".cmd\")))\n> +                       fMode |= S_IEXEC;\n> +               }\n\nThis breaks executable mode reporting for things like configure\nscripts and other shell scripts that may, or may not, be executable.\nAlso, you may want to turn off the executable state for some of these\nextensions (for example if com or cmd were not actually executable\nfiles). This makes it impossible to manipulate git repositories\nproperly on the MinGW platform.\n\nWould it be possible to use the git tree to manage the executable\nstate? That way, all files would not have their executable state set\nby default on Windows. The problem with this is how then to set the\nexecutable state? Having a git version of chmod may not be a good\nidea, but then how else are you going to reliably and efficiently\nmodify the files permissions on Windows?\n\nThe rest of the patch looks good on a brief initial scan.\n\n- Reece\n"},{"id":"52215","messageId":"46DAE025.900@trolltech.com","threadId":"9746","inReplyTo":"3f4fd2640709020832x656fa78djf29117690318ea48@mail.gmail.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T16:09:09Z","receivedAt":"2007-09-02T16:09:09Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Reece Dunn wrote:\n> On 02/09/07, Marius Storm-Olsen <marius@trolltech.com> wrote:\n>> This gives us a significant speedup when adding, committing and stat'ing files.\n>> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n>>\n>> +               if (ext && (!_stricmp(ext, \".exe\") ||\n>> +                           !_stricmp(ext, \".com\") ||\n>> +                           !_stricmp(ext, \".bat\") ||\n>> +                           !_stricmp(ext, \".cmd\")))\n>> +                       fMode |= S_IEXEC;\n>> +               }\n> \n> This breaks executable mode reporting for things like configure \n> scripts and other shell scripts that may, or may not, be executable. \n> Also, you may want to turn off the executable state for some of these\n> extensions (for example if com or cmd were not actually executable \n> files). This makes it impossible to manipulate git repositories \n> properly on the MinGW platform.\n\nActually, you don't really need the EXEC bit for Git to work. I just\nadded it for completeness. (We _could_ remove that too, since it's\nslowing us down slightly ;-)\n\nRemember that Git isn't using MSys for its builtins, so MinGW Git\ndoesn't understand the MSys notion of executable files anyways.\nThe MinGW port actually peeks at the beginning of a file (ignoring exe\nfiles), and sees if there's an interpreter there. If there is, it will\nexpand\n    git-foo args...\ninto\n    sh git-foo args...\nand execute the command. So, it's not really affected by this change.\n\nI haven't had any problems with this patch on my system, so could you\nexplain what you mean with 'this makes it impossible to manipulate git\nrepositories'?\n\n> Would it be possible to use the git tree to manage the executable \n> state? That way, all files would not have their executable state set \n> by default on Windows. The problem with this is how then to set the \n> executable state? Having a git version of chmod may not be a good \n> idea, but then how else are you going to reliably and efficiently \n> modify the files permissions on Windows?\n\nThe file-state-in-git-tree belongs in a different discussion. Have a\nlook at the '.gitignore, .gitattributes, .gitmodules, .gitprecious?,\n.gitacls? etc.' and 'tracking perms/ownership [was: empty directories]'\nthreads. Permissions are not a trivial topic, since systems represent\nthem differently. This patch just tries to reflect the read, write and\nexecute permissions as normal Windows would; and it only cares about\nfile extensions (and the PE header, if it exists).\n\nAlso note that my patch totally ignores the Group & Others part of the\npermission bits. Again, we're on Windows so we don't really care. We\n_could_ make it reflect the ACLs in Windows, but then we'd have to make\nit optional, since that's _really_ slow to 'stat'.\n\n> The rest of the patch looks good on a brief initial scan.\n\nThanks\n\n--\n.marius\n\n"},{"id":"52226","messageId":"3f4fd2640709020933sa2bdec0g532500ea49c179b5@mail.gmail.com","threadId":"9746","inReplyTo":"46DAE025.900@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2007-09-02T16:33:42Z","receivedAt":"2007-09-02T16:33:42Z","isPatch":true,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 02/09/07, Marius Storm-Olsen <marius@trolltech.com> wrote:\n> Reece Dunn wrote:\n> > On 02/09/07, Marius Storm-Olsen <marius@trolltech.com> wrote:\n> >> This gives us a significant speedup when adding, committing and stat'ing files.\n> >> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n> >>\n> >> +               if (ext && (!_stricmp(ext, \".exe\") ||\n> >> +                           !_stricmp(ext, \".com\") ||\n> >> +                           !_stricmp(ext, \".bat\") ||\n> >> +                           !_stricmp(ext, \".cmd\")))\n> >> +                       fMode |= S_IEXEC;\n> >> +               }\n> >\n> > This breaks executable mode reporting for things like configure\n> > scripts and other shell scripts that may, or may not, be executable.\n> > Also, you may want to turn off the executable state for some of these\n> > extensions (for example if com or cmd were not actually executable\n> > files). This makes it impossible to manipulate git repositories\n> > properly on the MinGW platform.\n>\n> Actually, you don't really need the EXEC bit for Git to work. I just\n> added it for completeness. (We _could_ remove that too, since it's\n> slowing us down slightly ;-)\n>\n> Remember that Git isn't using MSys for its builtins, so MinGW Git\n> doesn't understand the MSys notion of executable files anyways.\n> The MinGW port actually peeks at the beginning of a file (ignoring exe\n> files), and sees if there's an interpreter there. If there is, it will\n> expand\n>     git-foo args...\n> into\n>     sh git-foo args...\n> and execute the command. So, it's not really affected by this change.\n>\n> I haven't had any problems with this patch on my system, so could you\n> explain what you mean with 'this makes it impossible to manipulate git\n> repositories'?\n\nYou pull a repository that contains executable scripts that are\nrequired to work in order to build the system. You then make some\nmodifications to the local repository and run the 'git add .' command.\nSince this patch is reporting executable bits differently, the mode\nchange is stored as well as the local modifications. Now the changes\nare pushed upstream (along with the file mode changes).\n\nSomeone running a Linux machine, pulls your changes. When those files\nare checked out, the executable state of those scripts has now\nchanged, preventing the Linux user from running those scripts. _That_\nis what I meant. Or am I misunderstanding how git works in this case?\n\n> > Would it be possible to use the git tree to manage the executable\n> > state? That way, all files would not have their executable state set\n> > by default on Windows. The problem with this is how then to set the\n> > executable state? Having a git version of chmod may not be a good\n> > idea, but then how else are you going to reliably and efficiently\n> > modify the files permissions on Windows?\n>\n> The file-state-in-git-tree belongs in a different discussion. Have a\n> look at the '.gitignore, .gitattributes, .gitmodules, .gitprecious?,\n> .gitacls? etc.' and 'tracking perms/ownership [was: empty directories]'\n> threads. Permissions are not a trivial topic, since systems represent\n> them differently. This patch just tries to reflect the read, write and\n> execute permissions as normal Windows would; and it only cares about\n> file extensions (and the PE header, if it exists).\n\nI understand that this is not a trivial topic. I was thinking that\nthis different behaviour w.r.t. the executable permission will break\nthings when you have developers on both Linux and Windows, such as the\ncairo developers, for current git usage.\n\nI have not really been tracking those threads, but I will take a look at them.\n\n> Also note that my patch totally ignores the Group & Others part of the\n> permission bits. Again, we're on Windows so we don't really care. We\n> _could_ make it reflect the ACLs in Windows, but then we'd have to make\n> it optional, since that's _really_ slow to 'stat'.\n\nSure. Cygwin does use ACLs to implement stat which is why it is slow.\nSo anything that can speed git up here, without any breakage in\nfunctionality, is a good thing.\n\n- Reece\n"},{"id":"52236","messageId":"F0525923-6D9B-46AA-9678-8B1263C45FF7@silverinsanity.com","threadId":"9746","inReplyTo":"3f4fd2640709020933sa2bdec0g532500ea49c179b5@mail.gmail.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-09-02T16:47:32Z","receivedAt":"2007-09-02T16:47:32Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Sep 2, 2007, at 12:33 PM, Reece Dunn wrote:\n\n> You pull a repository that contains executable scripts that are\n> required to work in order to build the system. You then make some\n> modifications to the local repository and run the 'git add .' command.\n> Since this patch is reporting executable bits differently, the mode\n> change is stored as well as the local modifications. Now the changes\n> are pushed upstream (along with the file mode changes).\n>\n> Someone running a Linux machine, pulls your changes. When those files\n> are checked out, the executable state of those scripts has now\n> changed, preventing the Linux user from running those scripts. _That_\n> is what I meant. Or am I misunderstanding how git works in this case?\n\nThis is what \"git config core.fileMode false\" is for.  See git- \nconfig's man page for information (or Documentation/config.txt).\n\nWe already have a way to tell git that the \"executable bit\" is  \nworthless, and any Windows port should use it.\n\n~~ B\n"},{"id":"52237","messageId":"3f4fd2640709020953k2f5367a0o64870da9d8e04f68@mail.gmail.com","threadId":"9746","inReplyTo":"F0525923-6D9B-46AA-9678-8B1263C45FF7@silverinsanity.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2007-09-02T16:53:25Z","receivedAt":"2007-09-02T16:53:25Z","isPatch":true,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 02/09/07, Brian Gernhardt <benji@silverinsanity.com> wrote:\n>\n> On Sep 2, 2007, at 12:33 PM, Reece Dunn wrote:\n>\n> > You pull a repository that contains executable scripts that are\n> > required to work in order to build the system. You then make some\n> > modifications to the local repository and run the 'git add .' command.\n> > Since this patch is reporting executable bits differently, the mode\n> > change is stored as well as the local modifications. Now the changes\n> > are pushed upstream (along with the file mode changes).\n> >\n> > Someone running a Linux machine, pulls your changes. When those files\n> > are checked out, the executable state of those scripts has now\n> > changed, preventing the Linux user from running those scripts. _That_\n> > is what I meant. Or am I misunderstanding how git works in this case?\n>\n> This is what \"git config core.fileMode false\" is for.  See git-\n> config's man page for information (or Documentation/config.txt).\n>\n> We already have a way to tell git that the \"executable bit\" is\n> worthless, and any Windows port should use it.\n\nOk, so as the executable bit is worthless, there doesn't need to be\nany special casing in this patch to deal with it.\n\n- Reece\n"},{"id":"52238","messageId":"46DAED4F.2080407@trolltech.com","threadId":"9746","inReplyTo":"3f4fd2640709020953k2f5367a0o64870da9d8e04f68@mail.gmail.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T17:05:19Z","receivedAt":"2007-09-02T17:05:19Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Reece Dunn wrote:\n> On 02/09/07, Brian Gernhardt <benji@silverinsanity.com> wrote:\n>> On Sep 2, 2007, at 12:33 PM, Reece Dunn wrote:\n>>> You pull a repository that contains executable scripts that are \n>>> required to work in order to build the system. You then make some\n>>>  modifications to the local repository and run the 'git add .'\n>>> command. Since this patch is reporting executable bits\n>>> differently, the mode change is stored as well as the local\n>>> modifications. Now the changes are pushed upstream (along with\n>>> the file mode changes).\n>> \n>> We already have a way to tell git that the \"executable bit\" is \n>> worthless, and any Windows port should use it.\n> \n> Ok, so as the executable bit is worthless, there doesn't need to be \n> any special casing in this patch to deal with it.\n\nRight, this is true. And I was debating it with myself, and just added\nit for completion; at least for the first revision of the patch. It\ndoesn't really affect the performance all that much anyways. The\nconversion of the FileTime to unix time_t is far more heavy. (Which is\nwhy I'm debating to just ignore the access time)\n\nIf we could somehow rather use the FileTimes directly in the index,\ninstead of having to convert them, we could have even better performance\nwhen stat'ing on Windows. (However, it would result in an incompatible\nindex, so everyone would have to 'git update-index --refresh' on all\nrepositories before they can use the new version.)\n\n--\n.marius\n\n"},{"id":"52243","messageId":"Pine.LNX.4.64.0709021843270.28586@racer.site","threadId":"9746","inReplyTo":"46DAED4F.2080407@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-02T17:44:59Z","receivedAt":"2007-09-02T17:44:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 2 Sep 2007, Marius Storm-Olsen wrote:\n\n> The conversion of the FileTime to unix time_t is far more heavy.\n\nReally?  If so, we might consider storing FILETIME->dwHightDateTime and \n->dwLowDateTime in the index.\n\nBut I doubt it.  AFAICT _getting_ at the stat data is the expensive thing \nin Windows, not a 64-bit addition, subtraction and division.\n\nCiao,\nDscho\n"},{"id":"52244","messageId":"85sl5xoso1.fsf@lola.goethe.zz","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709021843270.28586@racer.site","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-02T17:58:54Z","receivedAt":"2007-09-02T17:58:54Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Hi,\n>\n> On Sun, 2 Sep 2007, Marius Storm-Olsen wrote:\n>\n>> The conversion of the FileTime to unix time_t is far more heavy.\n>\n> Really?  If so, we might consider storing FILETIME->dwHightDateTime and \n> ->dwLowDateTime in the index.\n>\n> But I doubt it.  AFAICT _getting_ at the stat data is the expensive thing \n> in Windows, not a 64-bit addition, subtraction and division.\n\n64-bit division conceivably could be somewhat expensive, but it sounds\nlike it should not be much compared to the cost of a system call.\nWhat is the code doing that division?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52246","messageId":"200709022016.54262.johannes.sixt@telecom.at","threadId":"9746","inReplyTo":"46DACE0D.5070501@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2007-09-02T18:16:54Z","receivedAt":"2007-09-02T18:16:54Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Sunday 02 September 2007 16:51, Marius Storm-Olsen wrote:\n> This gives us a significant speedup when adding, committing and stat'ing\n> files. (Also, since Windows doesn't really handle symlinks, it's fine that\n> stat just uses lstat)\n>\n> Signed-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>\n\nYour numbers show an improvement of 50% and more. That is terrific!\n\nI'll test it out an put the patch into mingw.git. I hope you don't mind if I \nalso include your analysis and statistics in the commit message. It's worth \nkeeping around! BTW, which of your email addresses would you like registered \nas author?\n\n> +\t\text = strrchr(file_name, '.');\n> +\t\tif (ext && (!_stricmp(ext, \".exe\") ||\n> +\t\t\t    !_stricmp(ext, \".com\") ||\n> +\t\t\t    !_stricmp(ext, \".bat\") ||\n> +\t\t\t    !_stricmp(ext, \".cmd\")))\n> +\t\t\tfMode |= S_IEXEC;\n> +\t\t}\n\nI'm slightly negative about this. For a native Windows project the executable \nbit does not matter, and for a cross-platform project this check is not \nsufficient, but can even become annoying (think of a file \nnamed 'www.google.com'). So we can just as well spare the few cycles.\n\n> +\t\tbuf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since\n> it's not a stat64 */\n\nHere's an idea for the future: With this self-made stat() implementation it \nshould also be possible to get rid of Windows's native struct stat: Make a \nprivate definition of it, too, and use all 64 bits.\n\n>  \t\treturn 0;\n> +\t}\n> +\terrno = ENOENT;\n\nOf course we need a bit more detailed error conditions, most importantly \nEACCES should be distinguished.\n\n> +/* Make git on Windows use git_lstat and git_stat instead of lstat and\n> stat */ +int git_lstat(const char *file_name, struct stat *buf);\n> +int git_stat(const char *file_name, struct stat *buf);\n> +#define lstat(x,y) git_lstat(x,y)\n> +#define stat(x,y) git_stat(x,y)\n\nI'd go the short route without git_stat() and\n\n#define stat(x,y) git_lstat(x,y)\n\n-- Hannes\n"},{"id":"52245","messageId":"46DAFE80.4040707@trolltech.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709021843270.28586@racer.site","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T18:18:40Z","receivedAt":"2007-09-02T18:18:40Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> On Sun, 2 Sep 2007, Marius Storm-Olsen wrote:\n>> The conversion of the FileTime to unix time_t is far more heavy.\n> \n> Really?  If so, we might consider storing FILETIME->dwHightDateTime\n> and ->dwLowDateTime in the index.\n> \n> But I doubt it.  AFAICT _getting_ at the stat data is the expensive\n> thing in Windows, not a 64-bit addition, subtraction and division.\n\nHaha, sure sure, _getting_ that stat data in the first place is the\nexpensive part on Windows. However, that's something you _have_ to do no\nmatter what, so there's no way around that.\n\nTurns out that it wasn't as bad as i thought. If you have\nfiletime_to_time_t() just return, say 116444736, I see\n    git add . improve with ~0.5 sec for 100K files\nand git status improve with 0.05 sec\n\nSurely, avoiding the tripple stat'ing in 'git status' would help a lot\nmore ;-) So, I guess we'll just leave the timestamp conversion as is,\nand avoid complicating the index.\n\n--\n.marius\n\n"},{"id":"52248","messageId":"46DB0478.8050402@trolltech.com","threadId":"9746","inReplyTo":"200709022016.54262.johannes.sixt@telecom.at","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T18:44:08Z","receivedAt":"2007-09-02T18:44:08Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Sixt wrote:\n> On Sunday 02 September 2007 16:51, Marius Storm-Olsen wrote:\n>> This gives us a significant speedup when adding, committing and stat'ing\n>> files. (Also, since Windows doesn't really handle symlinks, it's fine that\n>> stat just uses lstat)\n>>\n>> Signed-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>\n> \n> Your numbers show an improvement of 50% and more. That is terrific!\n\nYes, I was surprised myself about the impact. Didn't think it would make\n_such_ a difference. And if you compare it to the results we had before\nLinus' performance fix too, just checkout the performance improvements\nwe've had (based on Moe's test script):\n\n    Before                        Now\n    -------------------------     -------------------------\n    Command: git init             Command: git init\n    -------------------------     -------------------------\n    real    0m0.031s              real       0m0.078s\n    user    0m0.031s              user       0m0.031s\n    sys     0m0.000s              sys        0m0.000s\n    -------------------------     -------------------------\n    Command: git add .            Command: git add .\n    -------------------------     -------------------------\n    real    0m19.328s             real       0m12.187s\n    user    0m0.015s              user       0m0.015s\n    sys     0m0.015s              sys        0m0.015s\n    -------------------------     -------------------------\n    Command: git commit -a...     Command: git commit -a...\n    -------------------------     -------------------------\n    real    0m30.937s             real       0m17.297s\n    user    0m0.015s              user       0m0.015s\n    sys     0m0.015s              sys        0m0.015s\n    -------------------------     -------------------------\n    3x Command: git-status        3x Command: git-status\n    -------------------------     -------------------------\n    real    0m19.531s             real       0m5.344s\n    user    0m0.211s              user       0m0.015s\n    sys     0m0.136s              sys        0m0.031s\n\n    real    0m19.532s             real       0m5.390s\n    user    0m0.259s              user       0m0.031s\n    sys     0m0.091s              sys        0m0.000s\n\n    real    0m19.593s             real       0m5.344s\n    user    0m0.211s              user       0m0.015s\n    sys     0m0.152s              sys        0m0.016s\n    -------------------------     -------------------------\n    Command: git commit...        Command: git commit...\n             (single file)                 (single file)\n    -------------------------     -------------------------\n    real    0m36.688s             real       0m7.875s\n    user    0m0.031s              user       0m0.015s\n    sys     0m0.000s              sys        0m0.000s\n\n> I'll test it out an put the patch into mingw.git. I hope you don't mind if I \n> also include your analysis and statistics in the commit message. It's worth \n> keeping around! BTW, which of your email addresses would you like registered \n> as author?\n\nSure, include the stats if you'd like. You can use\nmstormo_git@storm-olsen.com for email address.\n\n>> +\t\text = strrchr(file_name, '.');\n>> +\t\tif (ext && (!_stricmp(ext, \".exe\") ||\n>> +\t\t\t    !_stricmp(ext, \".com\") ||\n>> +\t\t\t    !_stricmp(ext, \".bat\") ||\n>> +\t\t\t    !_stricmp(ext, \".cmd\")))\n>> +\t\t\tfMode |= S_IEXEC;\n>> +\t\t}\n> \n> I'm slightly negative about this. For a native Windows project the executable \n> bit does not matter, and for a cross-platform project this check is not \n> sufficient, but can even become annoying (think of a file \n> named 'www.google.com'). So we can just as well spare the few cycles.\n\nOk, that's fine by me. It was only added for completeness, and with no\nbenefits I'd say we drop it too.\n\n>> +\t\tbuf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since\n>> it's not a stat64 */\n> \n> Here's an idea for the future: With this self-made stat() implementation it \n> should also be possible to get rid of Windows's native struct stat: Make a \n> private definition of it, too, and use all 64 bits.\n\nYep, that will shave off one assignment, bit-shift and addition. Quick\noperations, but still worth while IMO. No point wasting cycles where we\ndon't have to.\n\n>>  \t\treturn 0;\n>> +\t}\n>> +\terrno = ENOENT;\n> \n> Of course we need a bit more detailed error conditions, most importantly \n> EACCES should be distinguished.\n\nRight, you want to do that in a second commit?\n\n>> +/* Make git on Windows use git_lstat and git_stat instead of lstat and\n>> stat */ +int git_lstat(const char *file_name, struct stat *buf);\n>> +int git_stat(const char *file_name, struct stat *buf);\n>> +#define lstat(x,y) git_lstat(x,y)\n>> +#define stat(x,y) git_stat(x,y)\n> \n> I'd go the short route without git_stat() and\n> \n> #define stat(x,y) git_lstat(x,y)\n\nPlease do, thanks.\n\n--\n.marius\n\n"},{"id":"52250","messageId":"200709022107.08804.johannes.sixt@telecom.at","threadId":"9746","inReplyTo":"46DB0478.8050402@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2007-09-02T19:07:08Z","receivedAt":"2007-09-02T19:07:08Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Sunday 02 September 2007 20:44, Marius Storm-Olsen wrote:\n> Johannes Sixt wrote:\n> > I'm slightly negative about this. For a native Windows project the\n> > executable bit does not matter, and for a cross-platform project this\n> > check is not sufficient, but can even become annoying (think of a file\n> > named 'www.google.com'). So we can just as well spare the few cycles.\n>\n> Ok, that's fine by me. It was only added for completeness, and with no\n> benefits I'd say we drop it too.\n\nI'll amend the patch accordingly.\n\n> >>  \t\treturn 0;\n> >> +\t}\n> >> +\terrno = ENOENT;\n> >\n> > Of course we need a bit more detailed error conditions, most importantly\n> > EACCES should be distinguished.\n>\n> Right, you want to do that in a second commit?\n\nYes, please. Please don't forget to take care of the trailing-slash annoyance.\n\n-- Hannes\n"},{"id":"52251","messageId":"46DB0F9C.2090306@trolltech.com","threadId":"9746","inReplyTo":"46DB0478.8050402@trolltech.com","subject":"[PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T19:31:40Z","receivedAt":"2007-09-02T19:31:40Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"This gives us a significant speedup when adding, committing and stat'ing files.\n(Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n\nSigned-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>\n---\n Revision #2 of the patch.\n For this one I change the filetime_to_time_t function to do the\n timestamp conversion inline in the FILETIME struct. That way we\n also avoid one assignment, bitshifting and addition.\n Sneaky, huh? ;-)\n New stats:\n    -------------------------\n    Command: git init\n    -------------------------\n\n    real    0m0.047s\n    user    0m0.031s\n    sys     0m0.000s\n\n    -------------------------\n    Command: git add .\n    -------------------------\n\n    real    0m12.016s\n    user    0m0.015s\n    sys     0m0.000s\n\n    -------------------------\n    Command: git commit -a...\n    -------------------------\n\n    real    0m17.031s\n    user    0m0.015s\n    sys     0m0.030s\n\n    -------------------------\n    3x Command: git-status\n    -------------------------\n\n    real    0m5.265s\n    user    0m0.015s\n    sys     0m0.015s\n\n    real    0m5.297s\n    user    0m0.015s\n    sys     0m0.000s\n\n    real    0m5.250s\n    user    0m0.015s\n    sys     0m0.016s\n\n    -------------------------\n    Command: git commit...\n    (single file)\n    -------------------------\n\n    real    0m7.859s\n    user    0m0.015s\n    sys     0m0.015s\n\n\n compat/mingw.c    |   41 +++++++++++++++++++++++++++++++++--------\n git-compat-util.h |    4 ++++\n 2 files changed, 37 insertions(+), 8 deletions(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 7711a3f..86a1419 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -23,19 +23,44 @@ int fchmod(int fildes, mode_t mode)\n \treturn -1;\n }\n\n-int lstat(const char *file_name, struct stat *buf)\n+static inline time_t filetime_to_time_t(const FILETIME *ft)\n+{\n+\tlong long *winTime = (long long*)ft;\n+\t*winTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */\n+\t*winTime /= 10000000;\t\t  /* Nano to seconds resolution */\n+\treturn (time_t)ft->dwLowDateTime;\n+}\n+\n+extern int _getdrive( void );\n+int git_lstat(const char *file_name, struct stat *buf)\n {\n \tint namelen;\n \tstatic char alt_name[PATH_MAX];\n-\n-\tif (!stat(file_name, buf))\n+\tWIN32_FILE_ATTRIBUTE_DATA fdata;\n+\n+\tif (GetFileAttributesExA(file_name, GetFileExInfoStandard, &fdata)) {\n+\t\tint fMode = S_IREAD;\n+\t\tif (fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)\n+\t\t\tfMode |= S_IFDIR;\n+\t\telse\n+\t\t\tfMode |= S_IFREG;\n+\t\tif (!(fdata.dwFileAttributes & FILE_ATTRIBUTE_READONLY))\n+\t\t\tfMode |= S_IWRITE;\n+\n+\t\tbuf->st_ino = 0;\n+\t\tbuf->st_gid = 0;\n+\t\tbuf->st_uid = 0;\n+\t\tbuf->st_nlink = 1;\n+\t\tbuf->st_mode = fMode;\n+\t\tbuf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since it's not a stat64 */\n+\t\tbuf->st_dev = buf->st_rdev = (_getdrive() - 1);\n+\t\tbuf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));\n+\t\tbuf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));\n+\t\tbuf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));\n \t\treturn 0;\n+\t}\n+\terrno = ENOENT;\n\n-\t/* if file_name ended in a '/', Windows returned ENOENT;\n-\t * try again without trailing slashes\n-\t */\n-\tif (errno != ENOENT)\n-\t\treturn -1;\n \tnamelen = strlen(file_name);\n \tif (namelen && file_name[namelen-1] != '/')\n \t\treturn -1;\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 1ba499f..4122465 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -488,6 +488,10 @@ int mingw_rename(const char*, const char*);\n extern void quote_argv(const char **dst, const char **src);\n extern const char *parse_interpreter(const char *cmd);\n\n+/* Make git on Windows use git_lstat instead of lstat and stat */\n+int git_lstat(const char *file_name, struct stat *buf);\n+#define lstat(x,y) git_lstat(x,y)\n+#define stat(x,y) git_lstat(x,y)\n #endif /* __MINGW32__ */\n\n #endif\n--\n1.5.3.GIT-dirty\n"},{"id":"52253","messageId":"20070902200218.GA2756@steel.home","threadId":"9746","inReplyTo":"46DACD93.9000509@trolltech.com","subject":"Re: Stats in Git","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-09-02T20:02:18Z","receivedAt":"2007-09-02T20:02:18Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marius Storm-Olsen, Sun, Sep 02, 2007 16:49:55 +0200:\n> By applying the diff below, you can see for yourself what happens when\n\njust use \"strace -e fstat,stat,lstat,stat64,lstat64 -f git-status\"\non sane platform.\n"},{"id":"52254","messageId":"46DB187B.9060809@trolltech.com","threadId":"9746","inReplyTo":"20070902200218.GA2756@steel.home","subject":"Re: Stats in Git","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-02T20:09:31Z","receivedAt":"2007-09-02T20:09:31Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Alex Riesen wrote:\n> Marius Storm-Olsen, Sun, Sep 02, 2007 16:49:55 +0200:\n>> By applying the diff below, you can see for yourself what happens when\n> \n> just use \"strace -e fstat,stat,lstat,stat64,lstat64 -f git-status\"\n> on sane platform.\n\nRight, I was doing this on Windows, where strace is rather.. limited, so\nI thought I'd just share the code for all to play with :-)\n\nBut, on my linux box:\n$ strace -e fstat,stat,lstat,stat64,lstat64 -f git-status 2>&1 | wc -l\n300195\n\n(Slightly more stats there, as expected, due to the listings of the\nshells stats too, and not just the builtins.)\n\n--\n.marius\n\n"},{"id":"52257","messageId":"200709022228.00733.robin.rosenberg.lists@dewire.com","threadId":"9746","inReplyTo":"46DB0F9C.2090306@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-09-02T20:27:59Z","receivedAt":"2007-09-02T20:27:59Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 02 september 2007 skrev Marius Storm-Olsen:\n> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n\nIt does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n\n-- robin\n"},{"id":"52260","messageId":"Pine.LNX.4.64.0709022133190.28586@racer.site","threadId":"9746","inReplyTo":"200709022228.00733.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-02T21:26:43Z","receivedAt":"2007-09-02T21:26:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 2 Sep 2007, Robin Rosenberg wrote:\n\n> s?ndag 02 september 2007 skrev Marius Storm-Olsen:\n> > (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n> \n> It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n\nOh?  *goes and tries to create one on a USB stick* No.  Besides, IIRC you \ncannot even create symlinks to another partition.  Copying a symlink will \ncopy the _linked_ file.  So to call this \"symlink\" is a little... uhm... \npreposterous.\n\nPlus, on a page linked from the link you posted, it says that it is \nonly supported from Vista onwards.  So you must be kidding me.\n\nCiao,\nDscho\n"},{"id":"52261","messageId":"20070902213856.GB2756@steel.home","threadId":"9746","inReplyTo":"200709022228.00733.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-09-02T21:38:56Z","receivedAt":"2007-09-02T21:38:56Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Robin Rosenberg, Sun, Sep 02, 2007 22:27:59 +0200:\n> söndag 02 september 2007 skrev Marius Storm-Olsen:\n> > (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n> \n> It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n> \n\nExcept they fscked it up, as usual for microsoft: it 's got a\nmandatory argument specifying what the target should be, file or\ndirectory. And they don't tell what happens when the argument is wrong\nor the target does not exists. Typical, too.\n"},{"id":"52263","messageId":"20070902214128.GC2756@steel.home","threadId":"9746","inReplyTo":"46DB0F9C.2090306@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-09-02T21:41:28Z","receivedAt":"2007-09-02T21:41:28Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Marius Storm-Olsen, Sun, Sep 02, 2007 21:31:40 +0200:\n> +\t\tbuf->st_ino = 0;\n\nYou sure about that? Ever wondered why it is not so on everywhere else?\n"},{"id":"52262","messageId":"200709022342.42733.robin.rosenberg.lists@dewire.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709022133190.28586@racer.site","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-09-02T21:42:42Z","receivedAt":"2007-09-02T21:42:42Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 02 september 2007 skrev Johannes Schindelin:\n> Hi,\n> \n> On Sun, 2 Sep 2007, Robin Rosenberg wrote:\n> \n> > s?ndag 02 september 2007 skrev Marius Storm-Olsen:\n> > > (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n> > \n> > It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n> \n> Oh?  *goes and tries to create one on a USB stick* No.  Besides, IIRC you \nSet core.symlinks = false for working on a broken file system\n\n> cannot even create symlinks to another partition.  Copying a symlink will \nThat is not the normal use for symlinks. It is a case where it breaks, but symbolic\nlinks in a git repo that points outside the repo is probably not a good idea, especially\nif it is a cross platform project. It is far less broken than today anyway.\n\n> copy the _linked_ file.  So to call this \"symlink\" is a little... uhm... \n> preposterous.\n\n$ ln -s Makefile x\n$ cp x y\n$ ls -ld x y\nlrwxrwxrwx 1 me me     8 sep  2 23:36 x -> Makefile\n-rw-r--r-- 1 me me 32164 sep  2 23:36 y\n\nSame behaviour as on linux.\n\n> Plus, on a page linked from the link you posted, it says that it is \n> only supported from Vista onwards.  So you must be kidding me.\n\ncore.symlinks = false if ithey aren't supported. You actually need\nadmin privileges too, but I don't know any windows developer who\nhasn't got that.\n\n-- robin\n"},{"id":"52265","messageId":"200709030004.33963.robin.rosenberg.lists@dewire.com","threadId":"9746","inReplyTo":"20070902213856.GB2756@steel.home","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-09-02T22:04:33Z","receivedAt":"2007-09-02T22:04:33Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"söndag 02 september 2007 skrev Alex Riesen:\n> Robin Rosenberg, Sun, Sep 02, 2007 22:27:59 +0200:\n> > söndag 02 september 2007 skrev Marius Storm-Olsen:\n> > > (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n> > \n> > It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n> > \n> \n> Except they fscked it up, as usual for microsoft: it 's got a\n> mandatory argument specifying what the target should be, file or\n> directory. And they don't tell what happens when the argument is wrong\n> or the target does not exists. Typical, too.\n\nWhy would this API be an exception?\n\n-- robin\n"},{"id":"52271","messageId":"Pine.LNX.4.64.0709030001030.28586@racer.site","threadId":"9746","inReplyTo":"200709022342.42733.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-02T23:02:10Z","receivedAt":"2007-09-02T23:02:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 2 Sep 2007, Robin Rosenberg wrote:\n\n> You actually need admin privileges too, but I don't know any windows \n> developer who hasn't got that.\n\nLike almost every developer in the corporate world?\n\nFact is: this support of symlinks is ridiculous.  Why not just admit it?\n\nCiao,\nDscho\n"},{"id":"52301","messageId":"46DBA5E8.105@trolltech.com","threadId":"9746","inReplyTo":"20070902214128.GC2756@steel.home","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T06:12:56Z","receivedAt":"2007-09-03T06:12:56Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Alex Riesen said the following on 02.09.2007 23:41:\n> Marius Storm-Olsen, Sun, Sep 02, 2007 21:31:40 +0200:\n>> +\t\tbuf->st_ino = 0;\n> \n> You sure about that? Ever wondered why it is not so on everywhere else?\n\nPretty sure. If you look at Windows' native version of stat, it will\nreturn you st_ino = 0. Or maybe you where referring to something else,\nand I just missed your point?\n\nAFAIK, the ino in the index is only to be _really_ sure that nothing\nhas changed with the file, and we can just skip it on Windows. If in\ndoubt, try running this on your Windows box:\n\n#include <windows.h>\n#include <stdio.h>\n#include <sys/types.h>\n#include <sys/stat.h>\n\nint main(int, char **)\n{\n    wchar_t DirSpec[] = L\".\\\\*\";\n    WIN32_FIND_DATA FindFileData;\n    HANDLE hFind = FindFirstFile(DirSpec, &FindFileData);\n    if (hFind == INVALID_HANDLE_VALUE) {\n        printf (\"Crap happened: %u\\n\", GetLastError());\n        return -1;\n    } \n\n    struct _stat buf;\n    while (FindNextFile(hFind, &FindFileData) != 0) \n    {\n        if (!_wstat(FindFileData.cFileName, &buf))\n            printf(\"file: %S, ino: %u\\n\", FindFileData.cFileName, buf.st_ino);\n    }\n\n    FindClose(hFind);\n    return 0;\n}\n\n\n\n-- \n.marius\n\n"},{"id":"52302","messageId":"46DBA672.9050308@trolltech.com","threadId":"9746","inReplyTo":"200709022228.00733.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T06:15:14Z","receivedAt":"2007-09-03T06:15:14Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Robin Rosenberg said the following on 02.09.2007 22:27:\n> söndag 02 september 2007 skrev Marius Storm-Olsen:\n>> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n> \n> It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n\nYeah, I know about Vista's improved support for symbolic links.\nHowever, I think we can let that lay for a while, until we decide to \nmake Git generate proper symlinks on Vista. I don't see it as a 1st \npriority at the moment, and we can always add the needed functionality \nin a separate stat() function later.\n\n-- \n.marius\n\n"},{"id":"52304","messageId":"46DBB2BE.8030505@eudaptics.com","threadId":"9746","inReplyTo":"200709022342.42733.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-03T07:07:42Z","receivedAt":"2007-09-03T07:07:42Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Robin Rosenberg schrieb:\n> $ ln -s Makefile x\n> $ cp x y\n> $ ls -ld x y\n> lrwxrwxrwx 1 me me     8 sep  2 23:36 x -> Makefile\n> -rw-r--r-- 1 me me 32164 sep  2 23:36 y\n\nAnd if I understand the documentation correctly, then\n\n$ mkdir foo && cd foo\n$ cat ../x\nx: No such file or directory\n\nRight?\n\nThe docs say that symlinks without backslash are relative to the current \ndirectory (!!!).\n\n-- Hannes\n"},{"id":"52306","messageId":"46DBBC1E.4010407@eudaptics.com","threadId":"9746","inReplyTo":"46DACE0D.5070501@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-03T07:47:42Z","receivedAt":"2007-09-03T07:47:42Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marius Storm-Olsen schrieb:\n> This gives us a significant speedup when adding, committing and stat'ing files.\n> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)\n\nUnfortunately, the patch fails t0010-racy-git.sh. I suspect the filetime \nconversion:\n\n> -int lstat(const char *file_name, struct stat *buf)\n> +static inline time_t filetime_to_time_t(const FILETIME *ft)\n> +{\n> +\tlong long winTime = ((long long)ft->dwHighDateTime << 32) + ft->dwLowDateTime;\n> +\twinTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */\n> +\twinTime /= 10000000;\t\t /* Nano to seconds resolution */\n\nShouldn't this be 1000000000 according to your comment? However, even if \nI make that change, the test still fails. Could you please look into this?\n\n> +\treturn (time_t)winTime;\n> +}\n\n-- Hannes\n"},{"id":"52308","messageId":"46DBBE0A.7050200@trolltech.com","threadId":"9746","inReplyTo":"46DBBC1E.4010407@eudaptics.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T07:55:54Z","receivedAt":"2007-09-03T07:55:54Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Sixt said the following on 03.09.2007 09:47:\n> Marius Storm-Olsen schrieb:\n>> This gives us a significant speedup when adding, committing and\n>> stat'ing files. (Also, since Windows doesn't really handle\n>> symlinks, it's fine that stat just uses lstat)\n> \n> Unfortunately, the patch fails t0010-racy-git.sh. I suspect the\n> filetime conversion:\n\nOk, I'll try to get to it later today.\n\n-- \n.marius\n\n"},{"id":"52314","messageId":"vpqodgkma9h.fsf@bauges.imag.fr","threadId":"9746","inReplyTo":"46DACD93.9000509@trolltech.com","subject":"Re: Stats in Git","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-09-03T08:19:22Z","receivedAt":"2007-09-03T08:19:22Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Marius Storm-Olsen <marius@trolltech.com> writes:\n\n> However, while look at that whole stat'ing situation in git, I saw\n> that doing 'git status' actually stats all the files _thrice_!\n> Yup, that's not 1 time, or 2 times, but actually 3(!) times before\n> 'git status' is content!\n\nMy experiments show 2 stats only:\n\n$ strace -f git status |& grep -e execve -e  foo                  \n[...]\n[pid 22492] execve(\"/home/moy/local/usr//bin/git\", [\"git\", \"update-index\", \"-q\", \"--unmerged\", \"--refresh\"], [/* 50 vars */]) = 0\n[pid 22492] lstat64(\"foo\", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0\n[pid 22493] execve(\"/home/moy/local/usr//bin/git\", [\"git\", \"runstatus\"], [/* 49 vars */]) = 0\n[pid 22493] lstat64(\"foo\", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0\n[...]\n\nOnce for \"git update-index --refresh\" and once more for \"git\nrunstatus\". Obviously, a builtin with one tree traversal only would\nprovide a good speedup.\n\n-- \nMatthieu\n"},{"id":"52338","messageId":"20070903112110.GE14853@genesis.frugalware.org","threadId":"9746","inReplyTo":"46DBB2BE.8030505@eudaptics.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2007-09-03T11:21:10Z","receivedAt":"2007-09-03T11:21:10Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Sep 03, 2007 at 09:07:42AM +0200, Johannes Sixt <j.sixt@eudaptics.com> wrote:\n> >$ ls -ld x y\n> >lrwxrwxrwx 1 me me     8 sep  2 23:36 x -> Makefile\n> >-rw-r--r-- 1 me me 32164 sep  2 23:36 y\n\n> And if I understand the documentation correctly, then\n\n> $ mkdir foo && cd foo\n> $ cat ../x\n> x: No such file or directory\n\n> Right?\n\ncorrect.\n\n- VMiklos\n"},{"id":"52340","messageId":"86y7fohtmw.fsf@lola.quinscape.zz","threadId":"9746","inReplyTo":"20070903112110.GE14853@genesis.frugalware.org","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-03T11:32:07Z","receivedAt":"2007-09-03T11:32:07Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Miklos Vajna <vmiklos@frugalware.org> writes:\n\n> On Mon, Sep 03, 2007 at 09:07:42AM +0200, Johannes Sixt <j.sixt@eudaptics.com> wrote:\n>> >$ ls -ld x y\n>> >lrwxrwxrwx 1 me me     8 sep  2 23:36 x -> Makefile\n>> >-rw-r--r-- 1 me me 32164 sep  2 23:36 y\n>\n>> And if I understand the documentation correctly, then\n>\n>> $ mkdir foo && cd foo\n>> $ cat ../x\n>> x: No such file or directory\n>\n>> Right?\n>\n> correct.\n\nHave you tested this, or is this from reading the documentation?  In\neither case: brilliant, but the former would be funnier (depending on\none's sense of humor, of course).\n\n-- \nDavid Kastrup\n"},{"id":"52342","messageId":"Pine.LNX.4.64.0709031238400.28586@racer.site","threadId":"9746","inReplyTo":"46DBA672.9050308@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-03T11:39:30Z","receivedAt":"2007-09-03T11:39:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n\n> Robin Rosenberg said the following on 02.09.2007 22:27:\n> > s?ndag 02 september 2007 skrev Marius Storm-Olsen:\n> > > (Also, since Windows doesn't really handle symlinks, it's fine that \n> > > stat just uses lstat)\n> > \n> > It does now: See \n> > http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n> \n> Yeah, I know about Vista's improved support for symbolic links. However, \n> I think we can let that lay for a while, until we decide to make Git \n> generate proper symlinks on Vista. I don't see it as a 1st priority at \n> the moment, and we can always add the needed functionality in a separate \n> stat() function later.\n\n... and force everybody to upgrade to Vista, thereby working for Microsoft \nfor free?  You _know_ that I will oppose that change.\n\nCiao,\nDscho\n"},{"id":"52344","messageId":"86odgkhsqd.fsf@lola.quinscape.zz","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709031238400.28586@racer.site","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-03T11:51:38Z","receivedAt":"2007-09-03T11:51:38Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n>\n>> Robin Rosenberg said the following on 02.09.2007 22:27:\n>> > s?ndag 02 september 2007 skrev Marius Storm-Olsen:\n>> > > (Also, since Windows doesn't really handle symlinks, it's fine that \n>> > > stat just uses lstat)\n>> > \n>> > It does now: See \n>> > http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n>> \n>> Yeah, I know about Vista's improved support for symbolic\n>> links. However, I think we can let that lay for a while, until we\n>> decide to make Git generate proper symlinks on Vista. I don't see\n>> it as a 1st priority at the moment, and we can always add the\n>> needed functionality in a separate stat() function later.\n>\n> ... and force everybody to upgrade to Vista,\n\nNonsense.  Supporting a feature is different from requiring a feature.\n\n> thereby working for Microsoft for free?  You _know_ that I will\n> oppose that change.\n\nIf Microsoft decides to shoot their users less in the foot than\npreviously, I don't think that we should take over the gun.\n\nHowever, if the symbolic link semantics hinted at elsewhere indeed are\nas broken as claimed and/or documented, the actual usefulness of\nsymbolic links seems so limited that we would not be doing their users\na favor by supporting relative symlinks.  And absolute links frankly\nhave very little place in a _work_ directory (and git does not\ncurrently keep track of enough things in order to make it useful as a\nfilesystem snapshot system).\n\nI would like to see actual test results to get a confirmation of\nwhether indeed relative symlinks are as broken under Vista as rumored.\nIf they are, it seems quite pointless supporting any symlinks under\nWindows at the moment.  Until I see actual test results, I would give\nMicrosoft the benefit of doubt.\n\n-- \nDavid Kastrup\n"},{"id":"52345","messageId":"46DBF5AC.6070400@trolltech.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709031238400.28586@racer.site","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T11:53:16Z","receivedAt":"2007-09-03T11:53:16Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin said the following on 03.09.2007 13:39:\n> On Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n>> Robin Rosenberg said the following on 02.09.2007 22:27:\n>>> It does now: See \n>>> http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n>> Yeah, I know about Vista's improved support for symbolic links.\n>> However, I think we can let that lay for a while, until we decide\n>> to make Git generate proper symlinks on Vista. I don't see it as\n>> a 1st priority at the moment, and we can always add the needed\n>> functionality in a separate stat() function later.\n> \n> ... and force everybody to upgrade to Vista, thereby working for\n> Microsoft for free?  You _know_ that I will oppose that change.\n\n;-) I wouldn't dream of it!\nNah, my comment was more 'allow usage of proper Symlinks on Vista' at \na later point. I would still argue that the default would be what we \nhave today. So, it would have to be an option.\nBut seeing what they've done to the symlinks there, it might be far \nfetched. We'll worry about that (much) later..\n\n-- \n.marius\n\n"},{"id":"52350","messageId":"Pine.LNX.4.64.0709031329590.28586@racer.site","threadId":"9746","inReplyTo":"46DBF5AC.6070400@trolltech.com","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-03T12:33:18Z","receivedAt":"2007-09-03T12:33:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n\n> Johannes Schindelin said the following on 03.09.2007 13:39:\n> > On Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n> > > Robin Rosenberg said the following on 02.09.2007 22:27:\n> > > > It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx\n> > > Yeah, I know about Vista's improved support for symbolic links.\n> > > However, I think we can let that lay for a while, until we decide\n> > > to make Git generate proper symlinks on Vista. I don't see it as\n> > > a 1st priority at the moment, and we can always add the needed\n> > > functionality in a separate stat() function later.\n> > \n> > ... and force everybody to upgrade to Vista, thereby working for\n> > Microsoft for free?  You _know_ that I will oppose that change.\n> \n> ;-) I wouldn't dream of it!\n\nHehe.\n\n> Nah, my comment was more 'allow usage of proper Symlinks on Vista' at a \n> later point. I would still argue that the default would be what we have \n> today. So, it would have to be an option.\n\nOkay, I could live with that.\n\n> But seeing what they've done to the symlinks there, it might be far \n> fetched. We'll worry about that (much) later..\n\nYes, it is funny how they do it over and over and over again.  Embrace, \n\"Extend\", Extinguish.  And I thought that eventually people would be \nclever enough to realise...\n\nCiao,\nDscho\n"},{"id":"52351","messageId":"46DC005F.70200@trolltech.com","threadId":"9746","inReplyTo":"46DBFA2A.7050003@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T12:38:55Z","receivedAt":"2007-09-03T12:38:55Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Marius Storm-Olsen said the following on 03.09.2007 14:12:\n>  With the our own implementations of lstat & fstat, the following test cases\n>  are now fixed:\n>      t4116-apply-reverte.sh\n>          ok 3: apply in reverse\n>      t4200-rerere.sh\n>          ok 17: young records still live\n>  However, the following test cases seems to fail now:\n>      t6024-recursive-merge.sh\n>          FAIL 1: setup tests\n>          FAIL 3: result contains a conflict\n>          FAIL 4: virtual trees were processed\n>          FAIL 5: refuse to merge binaries\n>  \n>  See attached test case logs.\n\nHow about that, reading the diff backwards :-)\nOh well, you see the issues based on the logs. Would be nice if you \nguys could also give the testcases a run to see if you get the same \nresult.\n\n-- \n.marius\n\n"},{"id":"52355","messageId":"Pine.LNX.4.64.0709031428080.28586@racer.site","threadId":"9746","inReplyTo":"46DBFA2A.7050003@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-03T13:33:22Z","receivedAt":"2007-09-03T13:33:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n\n> There was a problem with racy conditions, which this revision fixes.\n> The problem was that fstat was using the builtin implementation, which for\n> for some reason is off by some amount of seconds. (This is probably due to\n> some leap-year issue in one of the implementations. However, Microsoft tells\n> us to use 116444736000000000 in http://support.microsoft.com/kb/167296, so\n> I'll stick with that.)\n> Also, since both stat and lstat proved to be rather slow, having our own\n> version of fstat is probably also wise. At least we now control all the\n> stat'ing, so we _know_ they are compatible.\n> Also note that this revision makes git_lstat call itself after modifying\n> the filename, instead of the builtin stat, for the same reasons.\n\nAt least some of these informations should go into the commit message, \ntoo.\n\n> With the our own implementations of lstat & fstat, the following test cases\n> are now fixed:\n>     t4116-apply-reverte.sh\n>         ok 3: apply in reverse\n>     t4200-rerere.sh\n>         ok 17: young records still live\n> However, the following test cases seems to fail now:\n>     t6024-recursive-merge.sh\n>         FAIL 1: setup tests\n>         FAIL 3: result contains a conflict\n>         FAIL 4: virtual trees were processed\n>         FAIL 5: refuse to merge binaries\n> \n> See attached test case logs.\n> Are some of these test cases unstable, so the result will fluctuate on\n> Windows?\n\nI saw some funny stuff on Windows, like test cases succeeding when run \ninteractively, but failing when run from \"make test\".\n\nBTW it would have been way easier to apply your patch, had you followed \nSubmittingPatches...\n\nTo make it easier on others, I just uploaded it into the \"teststat\" branch \non 4msysgit.git (subject to removal in a few days).\n\nFirst comment: it seems git_fstat() is not declared properly, so there are \nquite a few compiler warnings.\n\nRunning the tests now.\n\nCiao,\nDscho\n"},{"id":"52356","messageId":"46DC10FE.1080805@eudaptics.com","threadId":"9746","inReplyTo":"46DBFA2A.7050003@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-03T13:49:50Z","receivedAt":"2007-09-03T13:49:50Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marius Storm-Olsen schrieb:\n> There was a problem with racy conditions, which this revision fixes.\n> The problem was that fstat was using the builtin implementation, which for\n> for some reason is off by some amount of seconds. (This is probably due to\n> some leap-year issue in one of the implementations. However, Microsoft \n> tells\n> us to use 116444736000000000 in http://support.microsoft.com/kb/167296, so\n> I'll stick with that.)\n\nThanks for the analysis and new patch. Indeed, FILETIME is UTC, which is \ngood; the native implementation returns local time, if I read the code \n(of msvcrt) correctly.\n\n> With the our own implementations of lstat & fstat, the following test cases\n> are now fixed:\n>     t4116-apply-reverte.sh\n>         ok 3: apply in reverse\n>     t4200-rerere.sh\n>         ok 17: young records still live\n> However, the following test cases seems to fail now:\n>     t6024-recursive-merge.sh\n>         FAIL 1: setup tests\n>         FAIL 3: result contains a conflict\n>         FAIL 4: virtual trees were processed\n>         FAIL 5: refuse to merge binaries\n> \n> See attached test case logs.\n> Are some of these test cases unstable, so the result will fluctuate on\n> Windows?\n\nI see many more failures. in:\n\nt4001-diff-rename.sh: 5\nt4101-apply-nonl.sh: all\nt4102-apply-rename.sh: 2,3,4\nt4116-apply-reverse.sh: 3\nt4200-rerere.sh: 12,13,17\nt5515-fetch-merge-logic.sh: 54\netc...\n\nThere is something fishy going on.\n\nBut at least the failure in t4116 is easy to work around:\n\ndiff --git a/t/t4116-apply-reverse.sh b/t/t4116-apply-reverse.sh\nindex fc2f622..f3e0c4a 100755\n--- a/t/t4116-apply-reverse.sh\n+++ b/t/t4116-apply-reverse.sh\n@@ -43,7 +43,8 @@ test_expect_success 'apply in reverse' '\n         git reset --hard second &&\n         git apply --reverse --binary --index patch &&\n         git diff >diff &&\n-       git diff /dev/null diff\n+       : > empty &&\n+       git diff empty diff\n\n  '\n\n-- Hannes\n"},{"id":"52357","messageId":"46DC1186.2010008@trolltech.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709031428080.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T13:52:06Z","receivedAt":"2007-09-03T13:52:06Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin said the following on 03.09.2007 15:33:\n> On Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n>> There was a problem with racy conditions, which this revision fixes.\n>> The problem was that fstat was using the builtin implementation, which for\n>> for some reason is off by some amount of seconds. (This is probably due to\n>> some leap-year issue in one of the implementations. However, Microsoft tells\n>> us to use 116444736000000000 in http://support.microsoft.com/kb/167296, so\n>> I'll stick with that.)\n>> Also, since both stat and lstat proved to be rather slow, having our own\n>> version of fstat is probably also wise. At least we now control all the\n>> stat'ing, so we _know_ they are compatible.\n>> Also note that this revision makes git_lstat call itself after modifying\n>> the filename, instead of the builtin stat, for the same reasons.\n> \n> At least some of these informations should go into the commit message, \n> too.\n\nSure\n\n>> With the our own implementations of lstat & fstat, the following test cases\n>> are now fixed:\n>>     t4116-apply-reverte.sh\n>>         ok 3: apply in reverse\n>>     t4200-rerere.sh\n>>         ok 17: young records still live\n>> However, the following test cases seems to fail now:\n>>     t6024-recursive-merge.sh\n>>         FAIL 1: setup tests\n>>         FAIL 3: result contains a conflict\n>>         FAIL 4: virtual trees were processed\n>>         FAIL 5: refuse to merge binaries\n>>\n>> See attached test case logs.\n>> Are some of these test cases unstable, so the result will fluctuate on\n>> Windows?\n> \n> I saw some funny stuff on Windows, like test cases succeeding when run \n> interactively, but failing when run from \"make test\".\n\nOk, I ran 'make test', so maybe that's it? I'll rerun them later.\n\n> BTW it would have been way easier to apply your patch, had you followed \n> SubmittingPatches...\n\nHeh, I actually tried, using the Thunderbird way. Of course the \nattachments are non-conforming :-) What was the problem? Whitespace \nissues, Windows EOL, attachments, or all of the above? :-)\n\n> To make it easier on others, I just uploaded it into the \"teststat\" branch \n> on 4msysgit.git (subject to removal in a few days).\n\nCool, thanks\n\n> First comment: it seems git_fstat() is not declared properly, so there are \n> quite a few compiler warnings.\n\n/me slaps self. Right, sorry 'bout that. I'll amend the declaration in \ngit-compat-util.h.\n\n> Running the tests now.\n\nGreat, thanks!\n-- \n.marius\n\n"},{"id":"52358","messageId":"46DC11F4.5060406@eudaptics.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709031428080.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-03T13:53:56Z","receivedAt":"2007-09-03T13:53:56Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> I saw some funny stuff on Windows, like test cases succeeding when run \n> interactively, but failing when run from \"make test\".\n\nThat's very likely the issue that we work around by inserting \"sleep 1\" \nat strategic points, which is a timing (race condition) issue and does \nnot depend on interactive vs. \"make test\".\n\n-- Hannes\n"},{"id":"52360","messageId":"Pine.LNX.4.64.0709031534300.28586@racer.site","threadId":"9746","inReplyTo":"46DC11F4.5060406@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-03T14:35:20Z","receivedAt":"2007-09-03T14:35:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Johannes Sixt wrote:\n\n> Johannes Schindelin schrieb:\n> > I saw some funny stuff on Windows, like test cases succeeding when run\n> > interactively, but failing when run from \"make test\".\n> \n> That's very likely the issue that we work around by inserting \"sleep 1\" at\n> strategic points, which is a timing (race condition) issue and does not\n> depend on interactive vs. \"make test\".\n\nMakes sense to me now.  Especially around t5510 -- t5701 I see those (and \nI do not run \"make test\" often, since it takes _ages_.\n\nThanks,\nDscho\n"},{"id":"52361","messageId":"Pine.LNX.4.64.0709031536060.28586@racer.site","threadId":"9746","inReplyTo":"46DC10FE.1080805@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-03T14:38:23Z","receivedAt":"2007-09-03T14:38:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Johannes Sixt wrote:\n\n> Marius Storm-Olsen schrieb:\n> > There was a problem with racy conditions, which this revision fixes.\n> > The problem was that fstat was using the builtin implementation, which for\n> > for some reason is off by some amount of seconds. (This is probably due to\n> > some leap-year issue in one of the implementations. However, Microsoft\n> > tells\n> > us to use 116444736000000000 in http://support.microsoft.com/kb/167296, so\n> > I'll stick with that.)\n> \n> Thanks for the analysis and new patch. Indeed, FILETIME is UTC, which is\n> good; the native implementation returns local time, if I read the code (of\n> msvcrt) correctly.\n> \n> > With the our own implementations of lstat & fstat, the following test cases\n> > are now fixed:\n> >     t4116-apply-reverte.sh\n> >         ok 3: apply in reverse\n> >     t4200-rerere.sh\n> >         ok 17: young records still live\n> > However, the following test cases seems to fail now:\n> >     t6024-recursive-merge.sh\n> >         FAIL 1: setup tests\n> >         FAIL 3: result contains a conflict\n> >         FAIL 4: virtual trees were processed\n> >         FAIL 5: refuse to merge binaries\n> > \n> > See attached test case logs.\n> > Are some of these test cases unstable, so the result will fluctuate on\n> > Windows?\n> \n> I see many more failures. in:\n> \n> t4001-diff-rename.sh: 5\n> t4101-apply-nonl.sh: all\n> t4102-apply-rename.sh: 2,3,4\n> t4116-apply-reverse.sh: 3\n> t4200-rerere.sh: 12,13,17\n> t5515-fetch-merge-logic.sh: 54\n> etc...\n\nFunny.  I do not get most of these:\n\nt4200-rerere,\nt5510-fetch,\nt5515-fetch-merge-logic,\nt5700-clone-reference,\nt5701-clone-local,\nt7004\n\nThis is all on top of 4msysgit's \"devel\" branch, and the t5* and t7004 \nfailed there already.\n\nOh, and I actually run from sh, not from cmd.  (Wouldn't you have \nguessed?)\n\nCiao,\nDscho\n"},{"id":"52362","messageId":"Pine.LNX.4.64.0709031538320.28586@racer.site","threadId":"9746","inReplyTo":"46DC1186.2010008@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-03T14:39:11Z","receivedAt":"2007-09-03T14:39:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n\n> Johannes Schindelin said the following on 03.09.2007 15:33:\n>\n> > BTW it would have been way easier to apply your patch, had you \n> > followed SubmittingPatches...\n> \n> Heh, I actually tried, using the Thunderbird way. Of course the \n> attachments are non-conforming :-) What was the problem? Whitespace \n> issues, Windows EOL, attachments, or all of the above? :-)\n\ngit am said that the patch was empty.\n\nCiao,\nDscho\n"},{"id":"52363","messageId":"46DC3320.1010408@trolltech.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709031536060.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T16:15:28Z","receivedAt":"2007-09-03T16:15:28Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> On Mon, 3 Sep 2007, Johannes Sixt wrote:\n>> I see many more failures. in:\n>>\n>> t4001-diff-rename.sh: 5\n>> t4101-apply-nonl.sh: all\n>> t4102-apply-rename.sh: 2,3,4\n>> t4116-apply-reverse.sh: 3\n>> t4200-rerere.sh: 12,13,17\n>> t5515-fetch-merge-logic.sh: 54\n>> etc...\n> \n> Funny.  I do not get most of these:\n> \n> t4200-rerere,\n> t5510-fetch,\n> t5515-fetch-merge-logic,\n> t5700-clone-reference,\n> t5701-clone-local,\n> t7004\n> \n> This is all on top of 4msysgit's \"devel\" branch, and the t5* and\n> t7004 failed there already.\n> \n> Oh, and I actually run from sh, not from cmd.  (Wouldn't you have \n> guessed?)\n\nI was also running the tests under sh, however on top of mingw.git, and\nnot 4msysgit.git.\n\n--\n.marius\n\n"},{"id":"52364","messageId":"46DC34A9.8020308@trolltech.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709031538320.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T16:22:01Z","receivedAt":"2007-09-03T16:22:01Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> On Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n>> Johannes Schindelin said the following on 03.09.2007 15:33:\n>>> BTW it would have been way easier to apply your patch, had you \n>>> followed SubmittingPatches...\n>> Heh, I actually tried, using the Thunderbird way. Of course the \n>> attachments are non-conforming :-) What was the problem? Whitespace\n>>  issues, Windows EOL, attachments, or all of the above? :-)\n> \n> git am said that the patch was empty.\n\nHmm, must be the attachments then. I'll use the 4msysgit.git repo from\nnow on. I assume it'll be ok if I +push to the teststat branch?\n\n--\n.marius\n\n"},{"id":"52366","messageId":"Pine.LNX.4.64.0709031753500.28586@racer.site","threadId":"9746","inReplyTo":"46DC3320.1010408@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-03T16:55:12Z","receivedAt":"2007-09-03T16:55:12Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n\n> Johannes Schindelin wrote:\n> \n> > t4200-rerere,\n> > t5510-fetch,\n> > t5515-fetch-merge-logic,\n> > t5700-clone-reference,\n> > t5701-clone-local,\n> > t7004\n> > \n> > This is all on top of 4msysgit's \"devel\" branch, and the t5* and t7004 \n> > failed there already.\n> > \n> > Oh, and I actually run from sh, not from cmd.  (Wouldn't you have \n> > guessed?)\n> \n> I was also running the tests under sh, however on top of mingw.git, and \n> not 4msysgit.git.\n\nI switched back recently, as more tests are succeeding in \n4msysgit.git's \"devel\" ATM.\n\nCiao,\nDscho\n"},{"id":"52367","messageId":"Pine.LNX.4.64.0709031755290.28586@racer.site","threadId":"9746","inReplyTo":"46DC34A9.8020308@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-03T16:56:10Z","receivedAt":"2007-09-03T16:56:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n\n> I'll use the 4msysgit.git repo from now on. I assume it'll be ok if I \n> +push to the teststat branch?\n\nI should think so.\n\nCiao,\nDscho\n"},{"id":"52375","messageId":"46DC5ED4.8050202@trolltech.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709031428080.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-03T19:21:56Z","receivedAt":"2007-09-03T19:21:56Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> To make it easier on others, I just uploaded it into the \"teststat\"\n> branch on 4msysgit.git (subject to removal in a few days).\n\nOk, I've updated the patch in the 4msysgit.git repo, 'teststat' branch.\nRFC, and please test.\n\nThe patch also incorporates some of Hannes local changes, with some\nmodifications. Hannes, does it look ok for you? You can add a tag to the\ncommit message if you'd like, and just +push it.\n\nOn Hannes' request (and to which I fully agree), I've gone back to the\nold implementation of filetime_to_time_t(), since it was a bit 'nasty'.\n(If we want to target CE in the future, it will quite possibly break)\n\nhttp://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f4f3fbddf6e0f16f66f94cedf66614e0e3643496\n\n> First comment: it seems git_fstat() is not declared properly, so\n> there are quite a few compiler warnings.\n\nThis is also fixed, of course.\n\nHope this is the final 'cut' :-)\n\nLater!\n--\n.marius\n\n"},{"id":"52383","messageId":"Pine.LNX.4.64.0709040319360.28586@racer.site","threadId":"9746","inReplyTo":"46DC5ED4.8050202@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-04T02:21:29Z","receivedAt":"2007-09-04T02:21:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Sep 2007, Marius Storm-Olsen wrote:\n\n> Johannes Schindelin wrote:\n> > To make it easier on others, I just uploaded it into the \"teststat\"\n> > branch on 4msysgit.git (subject to removal in a few days).\n> \n> Ok, I've updated the patch in the 4msysgit.git repo, 'teststat' branch.\n> RFC, and please test.\n\nI'm too tired for more, but the first test which fails (consistently) is \nt4200 here:\n\n* FAIL 17: young records still live\n\ttest -f .git/rr-cache/08f6c39f296af7e0dd1b3b7d8bba18d0365f605f/preimage\n&& test -f .git/rr-cache/4000000000000000000000000000000000000000/preimage\n\nCiao,\nDscho\n"},{"id":"52408","messageId":"46DD0C16.70101@eudaptics.com","threadId":"9746","inReplyTo":"46DC5ED4.8050202@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-04T07:41:10Z","receivedAt":"2007-09-04T07:41:10Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marius Storm-Olsen schrieb:\n> Johannes Schindelin wrote:\n>> To make it easier on others, I just uploaded it into the \"teststat\"\n>> branch on 4msysgit.git (subject to removal in a few days).\n> \n> Ok, I've updated the patch in the 4msysgit.git repo, 'teststat' branch.\n> RFC, and please test.\n\nThanks a lot! I've pushed it out in mingw.git's master.\n\nThe reason that t4200-rerere.sh fails is that we now store UTC in st_mtime. \nHowever, for the garbage-collection we compare this entry to a local time \nstamp. Therefore, I've pushed out a fixup patch at the top of mingw.git's \ndevel branch that converts mtime to local time \n(http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=1b62ecb31068af06c2fa7664f06c6c36316aac2c). \nWould you kindly conduct the performance test with this patch? I'm afraid \nthat this makes us substantially slower.\n\n-- Hannes\n"},{"id":"52414","messageId":"86tzqag6bw.fsf@lola.quinscape.zz","threadId":"9746","inReplyTo":"46DD0C16.70101@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-04T08:53:07Z","receivedAt":"2007-09-04T08:53:07Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Sixt <j.sixt@eudaptics.com> writes:\n\n> Marius Storm-Olsen schrieb:\n>> Johannes Schindelin wrote:\n>>> To make it easier on others, I just uploaded it into the \"teststat\"\n>>> branch on 4msysgit.git (subject to removal in a few days).\n>>\n>> Ok, I've updated the patch in the 4msysgit.git repo, 'teststat' branch.\n>> RFC, and please test.\n>\n> Thanks a lot! I've pushed it out in mingw.git's master.\n>\n> The reason that t4200-rerere.sh fails is that we now store UTC in\n> st_mtime. However, for the garbage-collection we compare this entry\n> to a local time stamp. Therefore, I've pushed out a fixup patch at\n> the top of mingw.git's devel branch that converts mtime to local\n> time\n> (http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=1b62ecb31068af06c2fa7664f06c6c36316aac2c). Would\n> you kindly conduct the performance test with this patch? I'm afraid\n> that this makes us substantially slower.\n\nWouldn't it make more sense to convert local time to mtime?  That's\none conversion per second at most rather than one conversion per file.\n\n-- \nDavid Kastrup\n"},{"id":"52416","messageId":"46DD3153.8060805@trolltech.com","threadId":"9746","inReplyTo":"46DD0C16.70101@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-04T10:20:03Z","receivedAt":"2007-09-04T10:20:03Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Sixt said the following on 04.09.2007 09:41:\n> Marius Storm-Olsen schrieb:\n>> Johannes Schindelin wrote:\n>>> To make it easier on others, I just uploaded it into the\n>>> \"teststat\" branch on 4msysgit.git (subject to removal in a few\n>>> days).\n>> Ok, I've updated the patch in the 4msysgit.git repo, 'teststat'\n>> branch. RFC, and please test.\n> \n> Thanks a lot! I've pushed it out in mingw.git's master.\n\nOps, already in master branch?\nOk, I found out that the custom fstat function was incomplete, so I \ncompleted it. However, since you've already pushed it to your main \nbranch, I've added it as a separate commit to the 4msysgit.git \n'teststat' branch. It might also explain some of the testfailures we \nwere seeing, but I haven't finished the test run yet. (So, consider \nthe patch something to play with, and don't commit it to your 'master' \nbranch yet! ;-)\n\nhttp://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127\n\n\n> The reason that t4200-rerere.sh fails is that we now store UTC in\n> st_mtime. However, for the garbage-collection we compare this entry\n> to a local time stamp. Therefore, I've pushed out a fixup patch at\n> the top of mingw.git's devel branch that converts mtime to local\n> time \n> (http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=1b62ecb31068af06c2fa7664f06c6c36316aac2c).\n> Would you kindly conduct the performance test with this patch? I'm\n> afraid that this makes us substantially slower.\n\nOk, I can give it a performance test, but I tend to agree with David \nKastrup there. It would be better if we rather fix the places where we \ncheck with the local timestamp instead; depending of course on how \nmany places we actually do this.\nWe'll see how much the timezone conversion in the custom stat \nfunctions actually hurt us performance wise.\n\n-- \n.marius\n\n"},{"id":"52420","messageId":"Pine.LNX.4.64.0709041145230.28586@racer.site","threadId":"9746","inReplyTo":"46DD0C16.70101@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-04T10:48:42Z","receivedAt":"2007-09-04T10:48:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Sep 2007, Johannes Sixt wrote:\n\n> Marius Storm-Olsen schrieb:\n> > Johannes Schindelin wrote:\n> > > To make it easier on others, I just uploaded it into the \"teststat\"\n> > > branch on 4msysgit.git (subject to removal in a few days).\n> > \n> > Ok, I've updated the patch in the 4msysgit.git repo, 'teststat' branch.\n> > RFC, and please test.\n> \n> Thanks a lot! I've pushed it out in mingw.git's master.\n> \n> The reason that t4200-rerere.sh fails is that we now store UTC in st_mtime.\n> However, for the garbage-collection we compare this entry to a local time\n> stamp.\n\nThanks for the explanation.\n\n> Therefore, I've pushed out a fixup patch at the top of mingw.git's devel \n> branch that converts mtime to local time\n\nOn Linux, we compare to UTC to begin with, right?  We should do that here, \ntoo...  So if time(NULL) does not return UTC on MinGW, we have to wrap \nthat function, too.\n\nCiao,\nDscho\n"},{"id":"52421","messageId":"46DD3943.8040403@eudaptics.com","threadId":"9746","inReplyTo":"46DD3153.8060805@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-04T10:53:55Z","receivedAt":"2007-09-04T10:53:55Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marius Storm-Olsen schrieb:\n> Johannes Sixt said the following on 04.09.2007 09:41:\n>> Thanks a lot! I've pushed it out in mingw.git's master.\n> \n> Ops, already in master branch?\n\nYes, it looked so polished ;)\n\n> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127 \n\nLooks good, although you should now handle INVALID_HANDLE_VALUE at the \nbeginning of git_fstat() like this:\n\n\tHANDLE fh = (HANDLE)_get_osfhandle(fd);\n\tif (fh == INVALID_HANDLE_VALUE)\n\t\treturn -1;\t/* errno has been set */\n\n\tif (GetFileInformationByHandle(...\n\n> Ok, I can give it a performance test, but I tend to agree with David \n> Kastrup there. It would be better if we rather fix the places where we \n> check with the local timestamp instead; depending of course on how many \n> places we actually do this.\n> We'll see how much the timezone conversion in the custom stat functions \n> actually hurt us performance wise.\n\nI'd make the decision on the grounds of a perfomance test. If it turns out \nthat the penalty is bearable, we should keep this stuff private to the MinGW \nbuild. Otherwise, we would need MinGW specific code at the call sites \n(unless we can hide the opposite conversion in some other wrapper function).\n\n... time passes ...\n\nOk, I just tested FileTimeToLocalFileTime() in a tight loop, and I can run \nit 100,000,000 times per second. So I'm confident that there won't be any \nnoticable degradation with my proposed change.\n\n-- Hannes\n"},{"id":"52423","messageId":"46DD3FC9.2020706@trolltech.com","threadId":"9746","inReplyTo":"46DD3943.8040403@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-04T11:21:45Z","receivedAt":"2007-09-04T11:21:45Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Sixt said the following on 04.09.2007 12:53:\n> Marius Storm-Olsen schrieb:\n>> Johannes Sixt said the following on 04.09.2007 09:41:\n>>> Thanks a lot! I've pushed it out in mingw.git's master.\n>> Ops, already in master branch?\n> \n> Yes, it looked so polished ;)\n> \n>> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127 \n> \n> Looks good, although you should now handle INVALID_HANDLE_VALUE at the \n> beginning of git_fstat() like this:\n> \n> \tHANDLE fh = (HANDLE)_get_osfhandle(fd);\n> \tif (fh == INVALID_HANDLE_VALUE)\n> \t\treturn -1;\t/* errno has been set */\n> \n> \tif (GetFileInformationByHandle(...\n\nActually, that's already handled.\nGetFileType will report FILE_TYPE_UNKNOWN (0), and GetLastError() will \nreturn a result != NO_ERROR (<-- so you can follow the codepath, but \nit actually returns ERROR_INVALID_HANDLE (6))\nSo, it will fall all the way through the function, and end up \nreturning -1, with errno = EBADF.\n\n(I use the\n     case FILE_TYPE_UNKNOWN:\n         if (GetLastError() != NO_ERROR)\n             break;\nconstruct, since the documentation says that an FILE_TYPE_UNKNOWN is \nstill a _valid_ handle iff GetLastError() returns NO_ERROR. So, then \nwe pass it on to the normal fstat function to let that figure out what \nwe're dealing with)\n\n\n>> Ok, I can give it a performance test, but I tend to agree with David \n>> Kastrup there. It would be better if we rather fix the places where we \n>> check with the local timestamp instead; depending of course on how many \n>> places we actually do this.\n>> We'll see how much the timezone conversion in the custom stat functions \n>> actually hurt us performance wise.\n> \n> I'd make the decision on the grounds of a perfomance test. If it turns out \n> that the penalty is bearable, we should keep this stuff private to the MinGW \n> build. Otherwise, we would need MinGW specific code at the call sites \n> (unless we can hide the opposite conversion in some other wrapper function).\n> \n> ... time passes ...\n> \n> Ok, I just tested FileTimeToLocalFileTime() in a tight loop, and I can run \n> it 100,000,000 times per second. So I'm confident that there won't be any \n> noticable degradation with my proposed change.\n\nOk. I haven't done the performance test with Git yet, but we'll see. \nIf it's not noticeable, I'll add it to all the timestamps we have.\n\n-- \n.marius\n\n"},{"id":"52424","messageId":"46DD4159.9060406@eudaptics.com","threadId":"9746","inReplyTo":"46DD3FC9.2020706@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-04T11:28:25Z","receivedAt":"2007-09-04T11:28:25Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marius Storm-Olsen schrieb:\n> Johannes Sixt said the following on 04.09.2007 12:53:\n>> Marius Storm-Olsen schrieb:\n>>> Johannes Sixt said the following on 04.09.2007 09:41:\n>>> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127 \n>>\n>>\n>> Looks good, although you should now handle INVALID_HANDLE_VALUE at the \n>> beginning of git_fstat() like this:\n> \n> Actually, that's already handled.\n\nIt's not a big deal: It's an unlikely code path, actually an indication of a \ncoding error, so you can leave your version.\n\n>> Ok, I just tested FileTimeToLocalFileTime() in a tight loop, and I can \n>> run it 100,000,000 times per second. So I'm confident that there won't \n>> be any noticable degradation with my proposed change.\n> \n> Ok. I haven't done the performance test with Git yet, but we'll see. If \n> it's not noticeable, I'll add it to all the timestamps we have.\n\nAck.\n\n-- Hannes\n"},{"id":"52425","messageId":"46DD433A.5040604@eudaptics.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709041145230.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-04T11:36:26Z","receivedAt":"2007-09-04T11:36:26Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> On Tue, 4 Sep 2007, Johannes Sixt wrote:\n>> Therefore, I've pushed out a fixup patch at the top of mingw.git's devel \n>> branch that converts mtime to local time\n> \n> On Linux, we compare to UTC to begin with, right?  We should do that here, \n> too...  So if time(NULL) does not return UTC on MinGW, we have to wrap \n> that function, too.\n\nAccording to MSDN, time(NULL) returns \"the number of seconds elapsed since \n[epoch] according to the system clock\". Please don't ask me what \"the system \nclock\" is.\n\nReading the implementation of time(), it starts with GetLocalTime(), \ndetermines whether daylight saving is in effect, and continues with another \nround of timezone adjustment - mind you: _not_ a timezone reversal (!!). \nDoesn't this look extremely bogus?\n\nIt seems we really need a wrapper for time().\n\n-- Hannes\n"},{"id":"52427","messageId":"46DD473A.8010602@trolltech.com","threadId":"9746","inReplyTo":"46DD433A.5040604@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-04T11:53:30Z","receivedAt":"2007-09-04T11:53:30Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Sixt said the following on 04.09.2007 13:36:\n> Johannes Schindelin schrieb:\n>> On Tue, 4 Sep 2007, Johannes Sixt wrote:\n>>> Therefore, I've pushed out a fixup patch at the top of\n>>> mingw.git's devel branch that converts mtime to local time\n>> On Linux, we compare to UTC to begin with, right?  We should do\n>> that here, too...  So if time(NULL) does not return UTC on MinGW,\n>> we have to wrap that function, too.\n> \n> According to MSDN, time(NULL) returns \"the number of seconds\n> elapsed since [epoch] according to the system clock\". Please don't\n> ask me what \"the system clock\" is.\n> \n> Reading the implementation of time(), it starts with\n> GetLocalTime(), determines whether daylight saving is in effect,\n> and continues with another round of timezone adjustment - mind you:\n> _not_ a timezone reversal (!!). Doesn't this look extremely bogus?\n> \n> It seems we really need a wrapper for time().\n\nHmm, could be.\nIn the meantime, I've pushed out a new patch\nhttp://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59\n\n/me starts another test run, to see how our tests are doing now..\n\n-- \n.marius\n\n"},{"id":"52430","messageId":"Pine.LNX.4.64.0709041324420.28586@racer.site","threadId":"9746","inReplyTo":"46DD433A.5040604@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-04T12:46:19Z","receivedAt":"2007-09-04T12:46:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Sep 2007, Johannes Sixt wrote:\n\n> Johannes Schindelin schrieb:\n> > On Tue, 4 Sep 2007, Johannes Sixt wrote:\n> > > Therefore, I've pushed out a fixup patch at the top of mingw.git's devel\n> > > branch that converts mtime to local time\n> > \n> > On Linux, we compare to UTC to begin with, right?  We should do that here,\n> > too...  So if time(NULL) does not return UTC on MinGW, we have to wrap that\n> > function, too.\n> \n> According to MSDN, time(NULL) returns \"the number of seconds elapsed since\n> [epoch] according to the system clock\". Please don't ask me what \"the system\n> clock\" is.\n\nI think I know.  From my QEmu adventures I know that DOS/Windows expects \nthe system clock to be set to local time, in contrast to _all_ other \noperating systems.\n\n> Reading the implementation of time(), it starts with GetLocalTime(), \n> determines whether daylight saving is in effect, and continues with \n> another round of timezone adjustment - mind you: _not_ a timezone \n> reversal (!!). Doesn't this look extremely bogus?\n> \n> It seems we really need a wrapper for time().\n\nI absolutely concur.  Something like this (most of it is blatantly copied \nfrom Marius' patch)?\n\n-- snip --\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 172e828..2984319 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -470,6 +470,17 @@ static inline int git_unlink(const char *pathname) \n{\n #include <time.h>\n struct tm *gmtime_r(const time_t *timep, struct tm *result);\n struct tm *localtime_r(const time_t *timep, struct tm *result);\n+static inline time_t mingw_time(void *dummy)\n+{\n+\tFILETIME ft;\n+\tGetSystemTimeAsFileTime(&ft);\n+\tlong long winTime = ((long long)ft.dwHighDateTime << 32) + \nft.dwLowDateTime;\n+\twinTime -= 116444736000000000LL; /* Windows to Unix Epoch \nconversion */\n+\twinTime /= 10000000;\t\t /* Nano to seconds resolution \n*/\n+\treturn (time_t)winTime;\n+\n+}\n+#define time mingw_time\n #define hstrerror strerror\n \n char *mingw_getcwd(char *pointer, int len);\n-- snap --\n\nCiao,\nDscho\n"},{"id":"52431","messageId":"Pine.LNX.4.64.0709041356070.28586@racer.site","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709041324420.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-04T12:57:38Z","receivedAt":"2007-09-04T12:57:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Sep 2007, Johannes Schindelin wrote:\n\n> On Tue, 4 Sep 2007, Johannes Sixt wrote:\n> \n> > Johannes Schindelin schrieb:\n> > > On Tue, 4 Sep 2007, Johannes Sixt wrote:\n> > > > Therefore, I've pushed out a fixup patch at the top of mingw.git's \n> > > > devel branch that converts mtime to local time\n> > > \n> > > On Linux, we compare to UTC to begin with, right?  We should do that \n> > > here, too...  So if time(NULL) does not return UTC on MinGW, we have \n> > > to wrap that function, too.\n> > \n> > According to MSDN, time(NULL) returns \"the number of seconds elapsed \n> > since [epoch] according to the system clock\". Please don't ask me what \n> > \"the system clock\" is.\n> \n> I think I know.  From my QEmu adventures I know that DOS/Windows expects \n> the system clock to be set to local time, in contrast to _all_ other \n> operating systems.\n\nNow I am utterly confused.  MSDN says\n\n\tFILETIME\n\n\tContains a 64-bit value representing the number of 100-nanosecond \n\tintervals since January 1, 1601 (UTC).\n\nHmm.\n\nCiao,\nDscho\n"},{"id":"52433","messageId":"46DD57B7.9090206@eudaptics.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709041324420.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-04T13:03:51Z","receivedAt":"2007-09-04T13:03:51Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> On Tue, 4 Sep 2007, Johannes Sixt wrote:\n>> Reading the implementation of time(), it starts with GetLocalTime(), \n>> determines whether daylight saving is in effect, and continues with \n>> another round of timezone adjustment - mind you: _not_ a timezone \n>> reversal (!!). Doesn't this look extremely bogus?\n>>\n>> It seems we really need a wrapper for time().\n> \n> I absolutely concur.  Something like this (most of it is blatantly copied \n> from Marius' patch)?\n\nWell, I don't think it'll make a difference. The tiny test program below \nprints twice the same number. My analysis of the time() implementation is \nobviously flawed.\n\n-- Hannes\n\n#include <windows.h>\n#include <stdio.h>\n#include <time.h>\n\nint main()\n{\n\ttime_t t = time(NULL);\n\tFILETIME ft;\n\n\tGetSystemTimeAsFileTime(&ft);\n\tlong long winTime = ((long long)ft.dwHighDateTime << 32)\n\t\t+ ft.dwLowDateTime;\n\twinTime -= 116444736000000000LL;\n\twinTime /= 10000000;\n\n\tprintf(\"%d %d\\n\", t, (int) winTime);\n\treturn 0;\n}\n"},{"id":"52439","messageId":"46DD63F5.5050002@trolltech.com","threadId":"9746","inReplyTo":"46DD473A.8010602@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-04T13:56:05Z","receivedAt":"2007-09-04T13:56:05Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Marius Storm-Olsen said the following on 04.09.2007 13:53:\n> In the meantime, I've pushed out a new patch\n> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59\n> \n> /me starts another test run, to see how our tests are doing now..\n\nNeat, with the custom stat() changes cherry-picked on top of \n4msysgit.git 'devel' branch, I only have one failing testcase\n     t6024-recursive-merge.sh\nwhen running\n     $ NO_SYMLINKS=1 make -k\n\nThe rest are passing with flying colors!\n\n-- \n.marius\n\n"},{"id":"52445","messageId":"46DD6694.6030701@eudaptics.com","threadId":"9746","inReplyTo":"46DD63F5.5050002@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-04T14:07:16Z","receivedAt":"2007-09-04T14:07:16Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Marius Storm-Olsen schrieb:\n> Marius Storm-Olsen said the following on 04.09.2007 13:53:\n>> In the meantime, I've pushed out a new patch\n>> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59 \n>>\n>>\n>> /me starts another test run, to see how our tests are doing now..\n> \n> Neat, with the custom stat() changes cherry-picked on top of \n> 4msysgit.git 'devel' branch, I only have one failing testcase\n>     t6024-recursive-merge.sh\n> when running\n>     $ NO_SYMLINKS=1 make -k\n> \n> The rest are passing with flying colors!\n\nAnd that one will eventually pass if only you try it often enough. See \n71ee4210c in mingw.git.\n\n-- Hannes\n"},{"id":"52446","messageId":"Pine.LNX.4.64.0709041514520.28586@racer.site","threadId":"9746","inReplyTo":"46DD63F5.5050002@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-04T14:16:38Z","receivedAt":"2007-09-04T14:16:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Sep 2007, Marius Storm-Olsen wrote:\n\n> Marius Storm-Olsen said the following on 04.09.2007 13:53:\n> > In the meantime, I've pushed out a new patch\n> > http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59\n> > \n> > /me starts another test run, to see how our tests are doing now..\n> \n> Neat, with the custom stat() changes cherry-picked on top of 4msysgit.git\n> 'devel' branch, I only have one failing testcase\n>     t6024-recursive-merge.sh\n> when running\n>     $ NO_SYMLINKS=1 make -k\n> \n> The rest are passing with flying colors!\n\nReally?  It is failing again?  IIRC it was Linus' patch (which I \ncherry-picked into 59f8c189a5) that fixed it for me.\n\nCiao,\nDscho\n"},{"id":"52449","messageId":"Pine.LNX.4.64.0709041529191.28586@racer.site","threadId":"9746","inReplyTo":"46DD63F5.5050002@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-04T14:30:08Z","receivedAt":"2007-09-04T14:30:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Sep 2007, Marius Storm-Olsen wrote:\n\n> Marius Storm-Olsen said the following on 04.09.2007 13:53:\n> > In the meantime, I've pushed out a new patch\n> > http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59\n> > \n> > /me starts another test run, to see how our tests are doing now..\n> \n> Neat, with the custom stat() changes cherry-picked on top of 4msysgit.git\n> 'devel' branch, I only have one failing testcase\n>     t6024-recursive-merge.sh\n> when running\n>     $ NO_SYMLINKS=1 make -k\n> \n> The rest are passing with flying colors!\n\nBad news.  I do not know if it was the newest version I tried, but I could \nno longer fetch... said something about some bad file.\n\nCiao,\nDscho\n"},{"id":"52451","messageId":"Pine.LNX.4.64.0709041530560.28586@racer.site","threadId":"9746","inReplyTo":"46DD6694.6030701@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-04T14:32:22Z","receivedAt":"2007-09-04T14:32:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Sep 2007, Johannes Sixt wrote:\n\n> Marius Storm-Olsen schrieb:\n> > Marius Storm-Olsen said the following on 04.09.2007 13:53:\n> > > In the meantime, I've pushed out a new patch\n> > > http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59 \n> > > \n> > > /me starts another test run, to see how our tests are doing now..\n> > \n> > Neat, with the custom stat() changes cherry-picked on top of 4msysgit.git\n> > 'devel' branch, I only have one failing testcase\n> >     t6024-recursive-merge.sh\n> > when running\n> >     $ NO_SYMLINKS=1 make -k\n> > \n> > The rest are passing with flying colors!\n> \n> And that one will eventually pass if only you try it often enough. See\n> 71ee4210c in mingw.git.\n\nDo you have Linus' patch applied?  The one where the config is read at the \nstart of write-tree?\n\nThe problem only occurred since we have core.crlf = input unilaterally \nnow.\n\nCiao,\nDscho\n"},{"id":"52454","messageId":"46DD6F2B.3060001@trolltech.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709041529191.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-04T14:43:55Z","receivedAt":"2007-09-04T14:43:55Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:\n>> Neat, with the custom stat() changes cherry-picked on top of\n>> 4msysgit.git 'devel' branch, I only have one failing testcase \n>> t6024-recursive-merge.sh when running $ NO_SYMLINKS=1 make -k\n>> \n>> The rest are passing with flying colors!\n> \n> Bad news.  I do not know if it was the newest version I tried, but I\n> could no longer fetch... said something about some bad file.\n\nThen you're missing this patch:\nhttp://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127\n\nI guess the quickest way is to manually apply this patch and recompile.\n(or add the '#undef fstat', and have git_fstat just 'return fstat(fd, buf)')\n\nThe problem is that without this patch fstat(0, buf) would fail with bad\nfiledescriptor instead of returning the st_mode = S_IFIFO.\n\n--\n.marius\n\n"},{"id":"52456","messageId":"Pine.LNX.4.64.0709041547240.28586@racer.site","threadId":"9746","inReplyTo":"46DD6F2B.3060001@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-04T14:48:17Z","receivedAt":"2007-09-04T14:48:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Sep 2007, Marius Storm-Olsen wrote:\n\n> Johannes Schindelin wrote:\n> > On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:\n> >> Neat, with the custom stat() changes cherry-picked on top of\n> >> 4msysgit.git 'devel' branch, I only have one failing testcase \n> >> t6024-recursive-merge.sh when running $ NO_SYMLINKS=1 make -k\n> >> \n> >> The rest are passing with flying colors!\n> > \n> > Bad news.  I do not know if it was the newest version I tried, but I\n> > could no longer fetch... said something about some bad file.\n> \n> Then you're missing this patch:\n> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127\n> \n> I guess the quickest way is to manually apply this patch and recompile.\n> (or add the '#undef fstat', and have git_fstat just 'return fstat(fd, buf)')\n> \n> The problem is that without this patch fstat(0, buf) would fail with bad\n> filedescriptor instead of returning the st_mode = S_IFIFO.\n\nI guessed as much, but could not fetch the patch, since fetch was broken \n;-)\n\nFor some utterly strange reason, \"git fetch\" accessed \"git-fetch\" in the \ncwd, not in /bin/...  Funny.\n\nCiao,\nDscho\n"},{"id":"52459","messageId":"46DD711D.2080209@eudaptics.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709041530560.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-04T14:52:13Z","receivedAt":"2007-09-04T14:52:13Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> Hi,\n> \n> On Tue, 4 Sep 2007, Johannes Sixt wrote:\n> \n>> Marius Storm-Olsen schrieb:\n>>> Marius Storm-Olsen said the following on 04.09.2007 13:53:\n>>>> In the meantime, I've pushed out a new patch\n>>>> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59 \n>>>>\n>>>> /me starts another test run, to see how our tests are doing now..\n>>> Neat, with the custom stat() changes cherry-picked on top of 4msysgit.git\n>>> 'devel' branch, I only have one failing testcase\n>>>     t6024-recursive-merge.sh\n>>> when running\n>>>     $ NO_SYMLINKS=1 make -k\n>>>\n>>> The rest are passing with flying colors!\n>> And that one will eventually pass if only you try it often enough. See\n>> 71ee4210c in mingw.git.\n> \n> Do you have Linus' patch applied?  The one where the config is read at the \n> start of write-tree?\n> \n> The problem only occurred since we have core.crlf = input unilaterally \n> now.\n\nYes, I have that patch, but I don't have core.crlf set.\n\nThere are a lot of tests that do a series of commits in a row, with file \nchanges such that the file size does _not_ change, aka \"racy git\" problem. \nThis problem is obviously not 100% fixed on MSys: We do not correctly detect \nthat there are files that might be modified (\"racily clean\" files). Some \ntests are prone to trigger the bug, others not.\n\n-- Hannes\n"},{"id":"52465","messageId":"86myw2eajl.fsf@lola.quinscape.zz","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709041547240.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-04T15:05:02Z","receivedAt":"2007-09-04T15:05:02Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:\n>\n>> The problem is that without this patch fstat(0, buf) would fail\n>> with bad filedescriptor instead of returning the st_mode = S_IFIFO.\n>\n> I guessed as much, but could not fetch the patch, since fetch was broken \n> ;-)\n>\n> For some utterly strange reason, \"git fetch\" accessed \"git-fetch\" in\n> the cwd, not in /bin/...  Funny.\n\nRegardless of what you write in your PATH variable, Windows will\n_always_ search for binaries first in your current work directory.  It\nis not really funny.\n\n-- \nDavid Kastrup\n"},{"id":"52484","messageId":"46DD888B.9020101@trolltech.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709041547240.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-04T16:32:11Z","receivedAt":"2007-09-04T16:32:11Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> On Tue, 4 Sep 2007, Marius Storm-Olsen wrote:\n>> Johannes Schindelin wrote:\n>>> Bad news.  I do not know if it was the newest version I tried,\n>>> but I could no longer fetch... said something about some bad\n>>> file.\n>> Then you're missing this patch: \n>> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=f15974add93bdfa92775c77c00e7c65aefd42127\n>> \n>> I guess the quickest way is to manually apply this patch and\n>> recompile. (or add the '#undef fstat', and have git_fstat just\n>> 'return fstat(fd, buf)')\n>> \n>> The problem is that without this patch fstat(0, buf) would fail\n>> with bad filedescriptor instead of returning the st_mode = S_IFIFO.\n> \n> I guessed as much, but could not fetch the patch, since fetch was\n> broken ;-)\n\nHeh, yeah, that's happened to me too before. One neat thing with this\ngitweb thingy though, is that you can actually grab the patch, like this\nhttp://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff_plain;h=f15974add93bdfa92775c77c00e7c65aefd42127\n\nNo excuse! ;-)\n\n--\n.marius\n\n"},{"id":"52520","messageId":"20070904210200.GA32472@nospam.com","threadId":"9746","inReplyTo":"Pine.LNX.4.64.0709041356070.28586@racer.site","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Rutger Nijlunsing","fromEmail":"rutger@nospam.com","sentAt":"2007-09-04T21:02:00Z","receivedAt":"2007-09-04T21:02:00Z","isPatch":true,"sender":{"key":"rutger.nijlunsing@gmail.com","avatar":null},"body":"On Tue, Sep 04, 2007 at 01:57:38PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 4 Sep 2007, Johannes Schindelin wrote:\n> \n> > On Tue, 4 Sep 2007, Johannes Sixt wrote:\n> > \n> > > Johannes Schindelin schrieb:\n> > > > On Tue, 4 Sep 2007, Johannes Sixt wrote:\n> > > > > Therefore, I've pushed out a fixup patch at the top of mingw.git's \n> > > > > devel branch that converts mtime to local time\n> > > > \n> > > > On Linux, we compare to UTC to begin with, right?  We should do that \n> > > > here, too...  So if time(NULL) does not return UTC on MinGW, we have \n> > > > to wrap that function, too.\n> > > \n> > > According to MSDN, time(NULL) returns \"the number of seconds elapsed \n> > > since [epoch] according to the system clock\". Please don't ask me what \n> > > \"the system clock\" is.\n> > \n> > I think I know.  From my QEmu adventures I know that DOS/Windows expects \n> > the system clock to be set to local time, in contrast to _all_ other \n> > operating systems.\n> \n> Now I am utterly confused.  MSDN says\n> \n> \tFILETIME\n> \n> \tContains a 64-bit value representing the number of 100-nanosecond \n> \tintervals since January 1, 1601 (UTC).\n> \n> Hmm.\n\n\n[Warning: war stories ahead...]\n\nIf you really, really want to know more:\n\nhttp://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm\n\n\n-- \nRutger Nijlunsing ---------------------------------- eludias ed dse.nl\nnever attribute to a conspiracy which can be explained by incompetence\n----------------------------------------------------------------------\n"},{"id":"52521","messageId":"85hcmajexb.fsf@lola.goethe.zz","threadId":"9746","inReplyTo":"46DD3943.8040403@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-04T21:31:28Z","receivedAt":"2007-09-04T21:31:28Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Sixt <j.sixt@eudaptics.com> writes:\n\n> Marius Storm-Olsen schrieb:\n>\n>> Ok, I can give it a performance test, but I tend to agree with\n>> David Kastrup there. It would be better if we rather fix the places\n>> where we check with the local timestamp instead; depending of\n>> course on how many places we actually do this.  We'll see how much\n>> the timezone conversion in the custom stat functions actually hurt\n>> us performance wise.\n>\n> I'd make the decision on the grounds of a perfomance test. If it\n> turns out that the penalty is bearable, we should keep this stuff\n> private to the MinGW build. Otherwise, we would need MinGW specific\n> code at the call sites (unless we can hide the opposite conversion\n> in some other wrapper function).\n>\n> ... time passes ...\n>\n> Ok, I just tested FileTimeToLocalFileTime() in a tight loop, and I\n> can run it 100,000,000 times per second. So I'm confident that there\n> won't be any noticable degradation with my proposed change.\n\nThe problem is that it will break in the hour when day light saving\ntime ends.  Or when you travel between timezones.\n\nLocal time is not continuous or unique.  That is why it is a bad idea\nto make decisions based on it.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52524","messageId":"3f4fd2640709041454jcb361d7p7e96ac1cf0062987@mail.gmail.com","threadId":"9746","inReplyTo":"20070904210200.GA32472@nospam.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2007-09-04T21:54:08Z","receivedAt":"2007-09-04T21:54:08Z","isPatch":true,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 04/09/07, Rutger Nijlunsing <rutger@nospam.com> wrote:\n> On Tue, Sep 04, 2007 at 01:57:38PM +0100, Johannes Schindelin wrote:\n> > Hi,\n> >\n> > On Tue, 4 Sep 2007, Johannes Schindelin wrote:\n> >\n> > > On Tue, 4 Sep 2007, Johannes Sixt wrote:\n> > >\n> > > > Johannes Schindelin schrieb:\n> > > > > On Tue, 4 Sep 2007, Johannes Sixt wrote:\n> > > > > > Therefore, I've pushed out a fixup patch at the top of mingw.git's\n> > > > > > devel branch that converts mtime to local time\n> > > > >\n> > > > > On Linux, we compare to UTC to begin with, right?  We should do that\n> > > > > here, too...  So if time(NULL) does not return UTC on MinGW, we have\n> > > > > to wrap that function, too.\n> > > >\n> > > > According to MSDN, time(NULL) returns \"the number of seconds elapsed\n> > > > since [epoch] according to the system clock\". Please don't ask me what\n> > > > \"the system clock\" is.\n> > >\n> > > I think I know.  From my QEmu adventures I know that DOS/Windows expects\n> > > the system clock to be set to local time, in contrast to _all_ other\n> > > operating systems.\n> >\n> > Now I am utterly confused.  MSDN says\n> >\n> >       FILETIME\n> >\n> >       Contains a 64-bit value representing the number of 100-nanosecond\n> >       intervals since January 1, 1601 (UTC).\n> >\n> > Hmm.\n>\n>\n> [Warning: war stories ahead...]\n>\n> If you really, really want to know more:\n>\n> http://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm\n\nHmm, this may explain something that I have been observing on\nWindows+cygwin. When I run `git diff`, I sometimes get it reporting\nthat all (from what I can tell) files have changed, like a `find .\n-type f -exec touch {} \\;` command was run.\n\nI was going to report this on a new thread, but this looks like a more\nrelevant place to do so.\n\nMy Windows machine is currently in Daylight Savings Time mode, and\nfrom my observations, I have only seen this repeat first thing the\nnext day. I am not sure why, but every 24hrs, it looks as if the file\ntime reported by and checked from git is different to that reported by\nstat.\n\nI have not had time yet to play around with the mingw port and this\nnew stat implementation to see if it addresses this issue.\n\n- Reece\n"},{"id":"52540","messageId":"46DE4B2E.70105@trolltech.com","threadId":"9746","inReplyTo":"20070904210200.GA32472@nospam.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-05T06:22:38Z","receivedAt":"2007-09-05T06:22:38Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Rutger Nijlunsing said the following on 04.09.2007 23:02:\n> On Tue, Sep 04, 2007 at 01:57:38PM +0100, Johannes Schindelin wrote:\n>> Now I am utterly confused.  MSDN says\n>> \tFILETIME\n>> \tContains a 64-bit value representing the number of 100-nanosecond \n>> \tintervals since January 1, 1601 (UTC).\n>> Hmm.\n> \n> [Warning: war stories ahead...]\n> If you really, really want to know more:\n> http://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm\n\nThanks, seems like it's the right decision then to ensure that we use \nUTC throughout Git on Windows\n\nHannes & Dscho, looks like we should revert\nhttp://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59\nthen, and rather apply Dscho's patch for a custom time() \nimplementation. Dscho, was the custom implementation of time() enough \nto fix the issues for you?\n\n-- \n.marius\n\n"},{"id":"52578","messageId":"Pine.LNX.4.64.0709051114340.28586@racer.site","threadId":"9746","inReplyTo":"46DE4B2E.70105@trolltech.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-05T10:15:33Z","receivedAt":"2007-09-05T10:15:33Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 5 Sep 2007, Marius Storm-Olsen wrote:\n\n> Rutger Nijlunsing said the following on 04.09.2007 23:02:\n> > On Tue, Sep 04, 2007 at 01:57:38PM +0100, Johannes Schindelin wrote:\n> > > Now I am utterly confused.  MSDN says\n> > > \tFILETIME\n> > > \tContains a 64-bit value representing the number of 100-nanosecond\n> > > intervals since January 1, 1601 (UTC).\n> > > Hmm.\n> > \n> > [Warning: war stories ahead...]\n> > If you really, really want to know more:\n> > http://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm\n> \n> Thanks, seems like it's the right decision then to ensure that we use UTC\n> throughout Git on Windows\n> \n> Hannes & Dscho, looks like we should revert \n> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=683775c00d9fb95bcbe4632f95b67a96b902fa59 \n> then, and rather apply Dscho's patch for a custom time() implementation. \n> Dscho, was the custom implementation of time() enough to fix the issues \n> for you?\n\nUmm.  I am helplessly overloaded with non-Git work, and just made sure \nthat it compiles ;-)  Besides, I did not really understand what I was \ndoing; just copying your code to convert from FILETIME to time_t.\n\nSorry,\nDscho\n"},{"id":"52589","messageId":"20070905160206.GY14853@genesis.frugalware.org","threadId":"9746","inReplyTo":"86y7fohtmw.fsf@lola.quinscape.zz","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2007-09-05T16:02:06Z","receivedAt":"2007-09-05T16:02:06Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Sep 03, 2007 at 01:32:07PM +0200, David Kastrup <dak@gnu.org> wrote:\n> >> And if I understand the documentation correctly, then\n> >\n> >> $ mkdir foo && cd foo\n> >> $ cat ../x\n> >> x: No such file or directory\n> >\n> >> Right?\n> >\n> > correct.\n> \n> Have you tested this, or is this from reading the documentation?  In\n> either case: brilliant, but the former would be funnier (depending on\n> one's sense of humor, of course).\n\numm, thanks for the notice, i was wrong:\n\n----\n$ cat ../x\nthis is makefile\n----\n\nthe situation what triggers the 'no such file' problem is:\n\n----\n$ touch foo/Makefile\n$ mkdir bar\n$ ln -s foo/Makefile bar\n$ cd bar\n$ cat Makefile\ncat: Makefile: No such file or directory\n----\n\n- VMiklos\n"},{"id":"52611","messageId":"85abs1hr6t.fsf@lola.goethe.zz","threadId":"9746","inReplyTo":"20070905160206.GY14853@genesis.frugalware.org","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-05T19:01:46Z","receivedAt":"2007-09-05T19:01:46Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\n[Vista and symbolic links]\n\nMiklos Vajna <vmiklos@frugalware.org> writes:\n\n> On Mon, Sep 03, 2007 at 01:32:07PM +0200, David Kastrup <dak@gnu.org> wrote:\n>> >> And if I understand the documentation correctly, then\n>> >\n>> >> $ mkdir foo && cd foo\n>> >> $ cat ../x\n>> >> x: No such file or directory\n>> >\n>> > correct.\n>> \n>> Have you tested this, or is this from reading the documentation?\n>\n> umm, thanks for the notice, i was wrong:\n>\n> ----\n> $ cat ../x\n> this is makefile\n> ----\n>\n> the situation what triggers the 'no such file' problem is:\n>\n> ----\n> $ touch foo/Makefile\n> $ mkdir bar\n> $ ln -s foo/Makefile bar\n> $ cd bar\n> $ cat Makefile\n> cat: Makefile: No such file or directory\n> ----\n\nThis is under Vista?  It would be the same under Unix.  A good rule of\nthumb is to create relative symbolic links _only_ when the current\nwork directory is identical with the target directory (and make it so\nif it isn't).  Alternatively, when one is completely awake and in full\npossession of all one's mental facilities.  The state that every geek\nis in 90% of the time according to his own perception, and 9% of the\ntime according to the computer.\n\nIf you tested this on Vista, chances are that they only bungled the\ndocumentation in this case (and of course, needing sysadmin privileges\nfor this would be just silly).  Not without precedence.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52767","messageId":"46E0285E.1000603@eudaptics.com","threadId":"9746","inReplyTo":"46DD0C16.70101@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-06T16:18:38Z","receivedAt":"2007-09-06T16:18:38Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Sixt schrieb:\n> Marius Storm-Olsen schrieb:\n>> Johannes Schindelin wrote:\n>>> To make it easier on others, I just uploaded it into the \"teststat\"\n>>> branch on 4msysgit.git (subject to removal in a few days).\n>>\n>> Ok, I've updated the patch in the 4msysgit.git repo, 'teststat' branch.\n>> RFC, and please test.\n> \n> Thanks a lot! I've pushed it out in mingw.git's master.\n> \n> The reason that t4200-rerere.sh fails is that we now store UTC in \n> st_mtime. However, for the garbage-collection we compare this entry to a \n> local time stamp.\n\nThis analysis is incorrect, I think. The reason we fail seems to be that \nt4200 uses test-chmtime, which uses utime(). Likely, we need a wrapper for \nthat one?\n\n-- Hannes\n"},{"id":"52769","messageId":"20070906162657.GF2329@genesis.frugalware.org","threadId":"9746","inReplyTo":"85abs1hr6t.fsf@lola.goethe.zz","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2007-09-06T16:26:57Z","receivedAt":"2007-09-06T16:26:57Z","isPatch":true,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Wed, Sep 05, 2007 at 09:01:46PM +0200, David Kastrup <dak@gnu.org> wrote:\n> > the situation what triggers the 'no such file' problem is:\n> >\n> > ----\n> > $ touch foo/Makefile\n> > $ mkdir bar\n> > $ ln -s foo/Makefile bar\n> > $ cd bar\n> > $ cat Makefile\n> > cat: Makefile: No such file or directory\n> > ----\n> \n> This is under Vista?  It would be the same under Unix.\n\nno, i never stated that this is Vista ;-) this is Linux.\n\n- VMiklos\n"},{"id":"52772","messageId":"85bqcfbvpe.fsf@lola.goethe.zz","threadId":"9746","inReplyTo":"20070906162657.GF2329@genesis.frugalware.org","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-06T16:33:01Z","receivedAt":"2007-09-06T16:33:01Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Miklos Vajna <vmiklos@frugalware.org> writes:\n\n> On Wed, Sep 05, 2007 at 09:01:46PM +0200, David Kastrup <dak@gnu.org> wrote:\n>> > the situation what triggers the 'no such file' problem is:\n>> >\n>> > ----\n>> > $ touch foo/Makefile\n>> > $ mkdir bar\n>> > $ ln -s foo/Makefile bar\n>> > $ cd bar\n>> > $ cat Makefile\n>> > cat: Makefile: No such file or directory\n>> > ----\n>> \n>> This is under Vista?  It would be the same under Unix.\n>\n> no, i never stated that this is Vista ;-) this is Linux.\n\nOk, so now we have established that we have not actually established\nanything with regard to relative links under Vista short of what\nMicrosoft claims in its developer information (which has its fair\nshare of misleading and wrong information).\n\nIf anybody is as fortunate as to actually have Vista available, it\nwould be nice if he corroborated that relative links under Vista are\nindeed (as Microsoft appears to claim) relative with regard to the\ncurrent work directory rather than the directory containing the link.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52773","messageId":"46E02C04.1060400@trolltech.com","threadId":"9746","inReplyTo":"46E0285E.1000603@eudaptics.com","subject":"Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-09-06T16:34:12Z","receivedAt":"2007-09-06T16:34:12Z","isPatch":true,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Johannes Sixt wrote:\n> Johannes Sixt schrieb:\n>> Marius Storm-Olsen schrieb:\n>>> Johannes Schindelin wrote:\n>>>> To make it easier on others, I just uploaded it into the\n>>>> \"teststat\" branch on 4msysgit.git (subject to removal in a few\n>>>> days).\n>>> \n>>> Ok, I've updated the patch in the 4msysgit.git repo, 'teststat'\n>>> branch. RFC, and please test.\n>> \n>> Thanks a lot! I've pushed it out in mingw.git's master.\n>> \n>> The reason that t4200-rerere.sh fails is that we now store UTC in \n>> st_mtime. However, for the garbage-collection we compare this entry\n>> to a local time stamp.\n> \n> This analysis is incorrect, I think. The reason we fail seems to be\n> that t4200 uses test-chmtime, which uses utime(). Likely, we need a\n> wrapper for that one?\n\nOk, could you make a quick patch to add a git_utime() (and probably\ngit_time()) and see if the tests pass without the UTC to Local time patch?\n\n--\n.marius\n\n"},{"id":"52818","messageId":"46E08DE9.4060701@11011.net","threadId":"9746","inReplyTo":"85bqcfbvpe.fsf@lola.goethe.zz","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"Douglas Stockwell","fromEmail":"doug@11011.net","sentAt":"2007-09-06T23:31:53Z","receivedAt":"2007-09-06T23:31:53Z","isPatch":true,"sender":{"key":"doug@11011.net","avatar":"https://gravatar.com/avatar/c9662328271b711eeb534c6a1ec17bb36278acd3170655ca622bde24e221ca87?d=mp&s=160"},"body":"David Kastrup wrote:\n> If anybody is as fortunate as to actually have Vista available, it\n> would be nice if he corroborated that relative links under Vista are\n> indeed (as Microsoft appears to claim) relative with regard to the\n> current work directory rather than the directory containing the link.\n\nI believe the wording \"resolves the path relative to the current \ndirectory\" actually refers to the creation of links, not to their use.\n\nC:\\stest>ver\n\nMicrosoft Windows [Version 6.0.6000]\n\nC:\\stest>echo test > file\n\nC:\\stest>mkdir links\n\nC:\\stest>cd links\n\nC:\\stest\\links>echo links > file\n\nC:\\stest\\links>mklink relative file\nsymbolic link created for relative <<===>> file\n\nC:\\stest\\links>mklink dotted .\\file\nsymbolic link created for dotted <<===>> .\\file\n\nC:\\stest\\links>mklink parent ..\\file\nsymbolic link created for parent <<===>> ..\\file\n\nC:\\stest\\links>mklink rooted \\stest\\links\\file\nsymbolic link created for rooted <<===>> \\stest\\links\\file\n\nC:\\stest\\links>mklink absolute c:file\nsymbolic link created for absolute <<===>> c:file\n\nC:\\stest\\links>dir\n07/09/2007  08:09 AM    <DIR>          .\n07/09/2007  08:09 AM    <DIR>          ..\n07/09/2007  08:09 AM    <SYMLINK>      absolute [C:\\stest\\links\\file]\n07/09/2007  08:09 AM    <SYMLINK>      dotted [.\\file]\n07/09/2007  08:09 AM                 8 file\n07/09/2007  08:09 AM    <SYMLINK>      parent [..\\file]\n07/09/2007  08:09 AM    <SYMLINK>      relative [file]\n07/09/2007  08:09 AM    <SYMLINK>      rooted [\\stest\\links\\file]\n\nC:\\stest\\links>cd ..\n\nC:\\stest>type links\\relative\nlinks\n\nC:\\stest>type links\\dotted\nlinks\n\nC:\\stest>type links\\parent\ntest\n\nC:\\stest>type links\\rooted\nlinks\n\nC:\\stest>type links\\absolute\nlinks\n\nC:\\stest>mkdir a\n\nC:\\stest>echo a > a\\file\n\nC:\\stest>move links a\n         1 dir(s) moved.\n\nC:\\stest>type a\\links\\relative\nlinks\n\nC:\\stest>type a\\links\\dotted\nlinks\n\nC:\\stest>type a\\links\\parent\na\n\nC:\\stest>type a\\links\\rooted\nThe system cannot find the path specified.\n\nC:\\stest>type a\\links\\absolute\nThe system cannot find the path specified.\n"},{"id":"52858","messageId":"85ir6n7zjb.fsf@lola.goethe.zz","threadId":"9746","inReplyTo":"46E08DE9.4060701@11011.net","subject":"Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-07T06:36:08Z","receivedAt":"2007-09-07T06:36:08Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Douglas Stockwell <doug@11011.net> writes:\n\n> David Kastrup wrote:\n>> If anybody is as fortunate as to actually have Vista available, it\n>> would be nice if he corroborated that relative links under Vista are\n>> indeed (as Microsoft appears to claim) relative with regard to the\n>> current work directory rather than the directory containing the link.\n>\n> I believe the wording \"resolves the path relative to the current\n> directory\" actually refers to the creation of links, not to their use.\n>\n> C:\\stest>ver\n>\n> Microsoft Windows [Version 6.0.6000]\n\n[Examples]\n\nGood.  So we will ultimately be able to support symlinks on some\nWindows versions.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"}]}