{"thread":{"id":"18447","subject":"Implementing stat() with FindFirstFile()","startedAt":"2009-03-21T15:47:38Z","lastAt":"2009-04-01T09:28:36Z","messageCount":14,"participants":["Magnus Bäck","Johannes Sixt","Johannes Schindelin","Björn Steinbrink","Heiko Voigt","Nazri Ramliy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"108797","messageId":"20090321154738.GA27249@jeeves.jpl.local","threadId":"18447","inReplyTo":null,"subject":"Implementing stat() with FindFirstFile()","fromName":"Magnus Bäck","fromEmail":"baeck@swipnet.se","sentAt":"2009-03-21T15:47:38Z","receivedAt":"2009-03-21T15:47:38Z","isPatch":false,"sender":{"key":"baeck@swipnet.se","avatar":null},"body":"Is there any reason why compat/win32.h uses GetFileAttributesEx()\ninstead of FindFirstFile() to implement the stat() call on Windows?\nThe current implementation requires each queried file to be opened\nand closed while FindFirstFile() only reads the directory.\n\nI made a couple of test programs that stat()ed the 176k files on my\ndisk and got the following best times with GetFileAttributesEx() and\nFindFirstFile() respectively:\n\n./getfattr.exe < filelist.txt 1.31s user 9.72s system 27% cpu 40.424 total\n./findfirst.exe < filelist.txt 1.92s user 13.98s system 95% cpu 16.681 total\n\nI searched the archive and found a couple of threads touching upon the\nsubject, but nothing conclusive.\n\nI have a (trivial) patch ready if such a change would be interesting.\n\n-- \nMagnus Bäck\nbaeck@swipnet.se\n"},{"id":"108810","messageId":"200903212055.15026.j6t@kdbg.org","threadId":"18447","inReplyTo":"20090321154738.GA27249@jeeves.jpl.local","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-03-21T19:55:14Z","receivedAt":"2009-03-21T19:55:14Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Samstag, 21. März 2009, Magnus Bäck wrote:\n> Is there any reason why compat/win32.h uses GetFileAttributesEx()\n> instead of FindFirstFile() to implement the stat() call on Windows?\n> The current implementation requires each queried file to be opened\n> and closed while FindFirstFile() only reads the directory.\n\nThere is: File times are extremely important for git. Unfortunately, MS's \nimplementation of stat and utime are broken, and they do use FindFirstFile(). \nRead up on the topic here:\n\nhttp://search.cpan.org/~shay/Win32-UTCFileTime-1.50/lib/Win32/UTCFileTime.pm\n\nTo quote the important sentence:\n\n\"The problem with Microsoft's stat(2) and utime(2) [...] is basically this: \nfile times reported by stat(2) or stored by utime(2) may change by an hour as \nwe move into or out of daylight saving time (DST) if the computer is set \nto \"Automatically adjust clock for daylight saving changes\" [...].\"\n\nBe sure to read section \"Background Reference\".\n\nBesides that, our stat() implementation is already ca. twice as fast as \nMSVCRT's stat(). (Thank you, Marius!)\n\n-- Hannes\n"},{"id":"109253","messageId":"20090324215416.GB27249@jeeves.jpl.local","threadId":"18447","inReplyTo":"200903212055.15026.j6t@kdbg.org","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Magnus Bäck","fromEmail":"baeck@swipnet.se","sentAt":"2009-03-24T21:54:16Z","receivedAt":"2009-03-24T21:54:16Z","isPatch":false,"sender":{"key":"baeck@swipnet.se","avatar":null},"body":"On Saturday, March 21, 2009 at 20:55 CET,\n Johannes Sixt wrote:\n\n> On Samstag, 21. März 2009, Magnus Bäck wrote:\n>\n> > Is there any reason why compat/win32.h uses GetFileAttributesEx()\n> > instead of FindFirstFile() to implement the stat() call on Windows?\n> > The current implementation requires each queried file to be opened\n> > and closed while FindFirstFile() only reads the directory.\n> \n> There is: File times are extremely important for git. Unfortunately,\n> MS's implementation of stat and utime are broken, and they do use\n> FindFirstFile(). Read up on the topic here:\n> \n> http://search.cpan.org/~shay/Win32-UTCFileTime-1.50/lib/Win32/UTCFileTime.pm\n\nQuite interesting, thanks. As it often is, \"obvious\" changes that\nhaven't been made aren't that obvious after all.\n\nFrom what I gather the problematic conversion takes place in the Win32\nlayer, in which case we might be able to call the ZwQueryDirectoryFile()\nkernel routine directly via ntdll.dll to obtain the file times straight\nfrom the file system. Has anyone explored that path, and would it be\nacceptable to make such a change?\n\n[...]\n\n-- \nMagnus Bäck\nbaeck@swipnet.se\n"},{"id":"109495","messageId":"49CB2BA5.1070100@viscovery.net","threadId":"18447","inReplyTo":"20090324215416.GB27249@jeeves.jpl.local","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-03-26T07:15:49Z","receivedAt":"2009-03-26T07:15:49Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Magnus Bäck schrieb:\n> From what I gather the problematic conversion takes place in the Win32\n> layer, in which case we might be able to call the ZwQueryDirectoryFile()\n> kernel routine directly via ntdll.dll to obtain the file times straight\n> from the file system. Has anyone explored that path, and would it be\n> acceptable to make such a change?\n\nIt depends.\n\nThe disadvantages are that this function is only available on Windows XP\nand later and that it is not present in the header files of MinGW gcc.\nIt's on you to prove that there are advantages that clearly outweigh these\ndisadvantages.\n\n-- Hannes\n"},{"id":"109582","messageId":"20090326213907.GC27249@jeeves.jpl.local","threadId":"18447","inReplyTo":"49CB2BA5.1070100@viscovery.net","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Magnus Bäck","fromEmail":"baeck@swipnet.se","sentAt":"2009-03-26T21:39:07Z","receivedAt":"2009-03-26T21:39:07Z","isPatch":false,"sender":{"key":"baeck@swipnet.se","avatar":null},"body":"On Thursday, March 26, 2009 at 08:15 CET,\n Johannes Sixt wrote:\n\n> Magnus Bäck schrieb:\n>\n> > From what I gather the problematic conversion takes place in\n> > the Win32 layer, in which case we might be able to call the\n> > ZwQueryDirectoryFile() kernel routine directly via ntdll.dll\n> > to obtain the file times straight from the file system. Has\n> > anyone explored that path, and would it be acceptable to make\n> > such a change?\n>\n> It depends.\n>\n> The disadvantages are that this function is only available on\n> Windows XP and later and that it is not present in the header\n> files of MinGW gcc.\n\nI'd be very surprised if ZwQueryDirectoryFile() hasn't always\nbeen around (I just verified ntdll.dll from NT 4.0), so that's\nnot a worry. Don't know why MSDN reports it as introduced in XP.\n\n> It's on you to prove that there are advantages that clearly\n> outweigh these disadvantages.\n\nAll right, I'll see if I can find time to take a look at this.\nI just wanted to check that it wasn't a project policy or whatever\nto bypass Win32.\n\n-- \nMagnus Bäck\nbaeck@swipnet.se\n"},{"id":"109593","messageId":"alpine.DEB.1.00.0903270320020.10279@pacific.mpi-cbg.de","threadId":"18447","inReplyTo":"20090326213907.GC27249@jeeves.jpl.local","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-27T02:25:01Z","receivedAt":"2009-03-27T02:25:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nMagnus, it is the official policy to reply-to-all on this list. This has \nbeen mentioned in the past quite often, and it will be mentioned in the \nfuture, too.\n\nYou actually forced me to manually look up and re-add Hannes' address. I \ndo not appreciate having to waste my time like that.\n\nIf that sounds negative, please understand that I am used to the ways of \nthis list, and when I am annoyed by somebody not fitting in, then it is \nnot totally _my_ mistake.\n\nOn Thu, 26 Mar 2009, Magnus Bäck wrote:\n\n> On Thursday, March 26, 2009 at 08:15 CET,\n> Johannes Sixt wrote:\n> \n> > Magnus Bäck schrieb:\n> >\n> > > From what I gather the problematic conversion takes place in the \n> > > Win32 layer, in which case we might be able to call the \n> > > ZwQueryDirectoryFile() kernel routine directly via ntdll.dll to \n> > > obtain the file times straight from the file system. Has anyone \n> > > explored that path, and would it be acceptable to make such a \n> > > change?\n> >\n> > It depends.\n> >\n> > The disadvantages are that this function is only available on Windows \n> > XP and later and that it is not present in the header files of MinGW \n> > gcc.\n> \n> I'd be very surprised if ZwQueryDirectoryFile() hasn't always been \n> around (I just verified ntdll.dll from NT 4.0), so that's not a worry. \n> Don't know why MSDN reports it as introduced in XP.\n\nAs the current maintainer of msysGit, I refuse to have something in the \ninstaller I ship that relies on not-at-all guaranteed interfaces.\n\n> > It's on you to prove that there are advantages that clearly outweigh \n> > these disadvantages.\n> \n> All right, I'll see if I can find time to take a look at this. I just \n> wanted to check that it wasn't a project policy or whatever to bypass \n> Win32.\n\nYou can do whatever you want... This is Open Source.\n\nHowever, I will try to stay with the officially supported functionality, \neven if that makes msysGit slower -- Windows will never reach the \nperformance levels of Linux anyway.\n\nCiao,\nDscho\n"},{"id":"109797","messageId":"20090329224803.GD27249@jeeves.jpl.local","threadId":"18447","inReplyTo":"alpine.DEB.1.00.0903270320020.10279@pacific.mpi-cbg.de","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Magnus Bäck","fromEmail":"baeck@swipnet.se","sentAt":"2009-03-29T22:48:03Z","receivedAt":"2009-03-29T22:48:03Z","isPatch":false,"sender":{"key":"baeck@swipnet.se","avatar":null},"body":"On Friday, March 27, 2009 at 03:25 CET,\n Johannes Schindelin wrote:\n\n> Magnus, it is the official policy to reply-to-all on this list. This\n> has been mentioned in the past quite often, and it will be mentioned\n> in the future, too.\n\nSorry, I was not aware. Doesn't seem to have been mentioned in the last\nmonth or so. Perhaps it could be included in the list introduction\nmessage? All people obviously won't read it, but some will.\n\n> You actually forced me to manually look up and re-add Hannes' address.\n> I do not appreciate having to waste my time like that.\n>\n> If that sounds negative, please understand that I am used to the ways\n> of this list, and when I am annoyed by somebody not fitting in, then\n> it is not totally _my_ mistake.\n\nA plain \"please use reply all\" would've sufficed.\n\n> On Thu, 26 Mar 2009, Magnus Bäck wrote:\n>\n> > I'd be very surprised if ZwQueryDirectoryFile() hasn't always been\n> > around (I just verified ntdll.dll from NT 4.0), so that's not a\n> > worry. Don't know why MSDN reports it as introduced in XP.\n>\n> As the current maintainer of msysGit, I refuse to have something in\n> the installer I ship that relies on not-at-all guaranteed interfaces.\n\nAlthough I do appreciate the importance of guaranteed interfaces,\nI am also pragmatic. An incompatible change in ntdll.dll would break\nvast amounts of programs, including cygwin. There is a lot to be said\nabout Microsoft and their APIs, but I don't think they have a habit of\nchanging ABIs or function semantics for userland libraries that have\nbeen around for 15 years.\n\n> > All right, I'll see if I can find time to take a look at this. I\n> > just wanted to check that it wasn't a project policy or whatever\n> > to bypass Win32.\n>\n> You can do whatever you want... This is Open Source.\n>\n> However, I will try to stay with the officially supported functionality,\n> even if that makes msysGit slower -- Windows will never reach the\n> performance levels of Linux anyway.\n\nOkay, thanks. Just like you I hate wasting time, in my case with patches\nthat'll be refused.\n\n-- \nMagnus Bäck\nbaeck@swipnet.se\n"},{"id":"109802","messageId":"alpine.DEB.1.00.0903300245080.6454@intel-tinevez-2-302","threadId":"18447","inReplyTo":"20090329224803.GD27249@jeeves.jpl.local","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-30T00:52:47Z","receivedAt":"2009-03-30T00:52:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 30 Mar 2009, Magnus Bäck wrote:\n\n> On Friday, March 27, 2009 at 03:25 CET,\n> Johannes Schindelin wrote:\n> \n> > Magnus, it is the official policy to reply-to-all on this list. This\n> > has been mentioned in the past quite often, and it will be mentioned\n> > in the future, too.\n> \n> Sorry, I was not aware. Doesn't seem to have been mentioned in the last\n> month or so. Perhaps it could be included in the list introduction\n> message? All people obviously won't read it, but some will.\n> \n> > You actually forced me to manually look up and re-add Hannes' address.\n> > I do not appreciate having to waste my time like that.\n> >\n> > If that sounds negative, please understand that I am used to the ways\n> > of this list, and when I am annoyed by somebody not fitting in, then\n> > it is not totally _my_ mistake.\n> \n> A plain \"please use reply all\" would've sufficed.\n\nI do recognize that I was too harsh: I apologize!\n\n> > On Thu, 26 Mar 2009, Magnus Bäck wrote:\n> >\n> > > I'd be very surprised if ZwQueryDirectoryFile() hasn't always been\n> > > around (I just verified ntdll.dll from NT 4.0), so that's not a\n> > > worry. Don't know why MSDN reports it as introduced in XP.\n> >\n> > As the current maintainer of msysGit, I refuse to have something in\n> > the installer I ship that relies on not-at-all guaranteed interfaces.\n> \n> Although I do appreciate the importance of guaranteed interfaces,\n> I am also pragmatic. An incompatible change in ntdll.dll would break\n> vast amounts of programs, including cygwin. There is a lot to be said\n> about Microsoft and their APIs, but I don't think they have a habit of\n> changing ABIs or function semantics for userland libraries that have\n> been around for 15 years.\n\nThat does not give me the warm and fuzzy feeling I want to have when \nshipping a new Git for Windows.\n\nHad you pointed to some document that states that the function has been in \nall NT-based versions, that would have done the trick.\n\n> > > All right, I'll see if I can find time to take a look at this. I \n> > > just wanted to check that it wasn't a project policy or whatever to \n> > > bypass Win32.\n> >\n> > You can do whatever you want... This is Open Source.\n> >\n> > However, I will try to stay with the officially supported functionality,\n> > even if that makes msysGit slower -- Windows will never reach the\n> > performance levels of Linux anyway.\n> \n> Okay, thanks. Just like you I hate wasting time, in my case with patches\n> that'll be refused.\n\nSorry, that was not at all what I meant.\n\nOf course, I wanted to avoid having time wasted: yours and mine. But if \nyou find said document, or another proof that the function was not \nintroduced by pure chance in some of NT's service packs, then that's \nperfectly fine with me.\n\nBut if it is, say, only in NT when upgrading to Explorer 6 or newer, I do \nnot want to take it: I personally know a machine running NT without \nservice packs, and with Internet Explorer 5.5, because every attempt at \nupgrading freezes the complete machine 10 seconds into the login screen. \nAnd no, the machine cannot run with another setup, because there is a \n6-figure microscope plugged in that refuses to be controlled by anything \nelse than the proprietary software that just happens to run only on said \nNT4, with said IE5.5.\n\nAgain, I am sorry for my harsh reaction, but please understand that I \n_need_ better proof that nobody will be bitten by your change (chances are \nthat I'd have to clean it up...).\n\nAfter all, in the short time since the release of 1.6.2.1, we had over \n4000 downloads already.\n\nCiao,\nDscho\n"},{"id":"109831","messageId":"20090330051118.GA2681@atjola.homenet","threadId":"18447","inReplyTo":"alpine.DEB.1.00.0903300245080.6454@intel-tinevez-2-302","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-03-30T05:11:18Z","receivedAt":"2009-03-30T05:11:18Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.03.30 02:52:47 +0200, Johannes Schindelin wrote:\n> On Mon, 30 Mar 2009, Magnus Bäck wrote:\n> > On Friday, March 27, 2009 at 03:25 CET,\n> > Johannes Schindelin wrote:\n> > > On Thu, 26 Mar 2009, Magnus Bäck wrote:\n> > > > I'd be very surprised if ZwQueryDirectoryFile() hasn't always been\n> > > > around (I just verified ntdll.dll from NT 4.0), so that's not a\n> > > > worry. Don't know why MSDN reports it as introduced in XP.\n> > >\n> > > As the current maintainer of msysGit, I refuse to have something in\n> > > the installer I ship that relies on not-at-all guaranteed interfaces.\n> > \n> > Although I do appreciate the importance of guaranteed interfaces,\n> > I am also pragmatic. An incompatible change in ntdll.dll would break\n> > vast amounts of programs, including cygwin. There is a lot to be said\n> > about Microsoft and their APIs, but I don't think they have a habit of\n> > changing ABIs or function semantics for userland libraries that have\n> > been around for 15 years.\n> \n> Had you pointed to some document that states that the function has been in \n> all NT-based versions, that would have done the trick.\n\nNot official documentation, but at least from some MS guy it seems:\nhttp://www.osronline.com/showThread.cfm?link=73086 (last message).\n\nApparently, it was in NT3.x, but they document only what's actually\ndefined in the header.\n\nBjörn, feeling weird for trying to help with some Windows issue...\n"},{"id":"109944","messageId":"20090330220709.GA68118@macbook.lan","threadId":"18447","inReplyTo":"20090330051118.GA2681@atjola.homenet","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2009-03-30T22:07:10Z","receivedAt":"2009-03-30T22:07:10Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Mar 30, 2009 at 07:11:18AM +0200, Björn Steinbrink wrote:\n> On 2009.03.30 02:52:47 +0200, Johannes Schindelin wrote:\n> > On Mon, 30 Mar 2009, Magnus Bäck wrote:\n> > > On Friday, March 27, 2009 at 03:25 CET,\n> > > Johannes Schindelin wrote:\n> > > > On Thu, 26 Mar 2009, Magnus Bäck wrote:\n> > > > > I'd be very surprised if ZwQueryDirectoryFile() hasn't always been\n> > > > > around (I just verified ntdll.dll from NT 4.0), so that's not a\n> > > > > worry. Don't know why MSDN reports it as introduced in XP.\n> > > >\n> > > > As the current maintainer of msysGit, I refuse to have something in\n> > > > the installer I ship that relies on not-at-all guaranteed interfaces.\n> > > \n> > > Although I do appreciate the importance of guaranteed interfaces,\n> > > I am also pragmatic. An incompatible change in ntdll.dll would break\n> > > vast amounts of programs, including cygwin. There is a lot to be said\n> > > about Microsoft and their APIs, but I don't think they have a habit of\n> > > changing ABIs or function semantics for userland libraries that have\n> > > been around for 15 years.\n> > \n> > Had you pointed to some document that states that the function has been in \n> > all NT-based versions, that would have done the trick.\n> \n> Not official documentation, but at least from some MS guy it seems:\n> http://www.osronline.com/showThread.cfm?link=73086 (last message).\n> \n> Apparently, it was in NT3.x, but they document only what's actually\n> defined in the header.\n\nHow about runtime checking? You could do GetProcAddress(...) and if you\ndon't get it use the old behaviour. I mean if it really is faster why\nnot let Users of recent systems benefit from it.\n\ncheers Heiko\n"},{"id":"109950","messageId":"alpine.DEB.1.00.0903310128410.10279@pacific.mpi-cbg.de","threadId":"18447","inReplyTo":"20090330220709.GA68118@macbook.lan","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-30T23:29:17Z","receivedAt":"2009-03-30T23:29:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 31 Mar 2009, Heiko Voigt wrote:\n\n> On Mon, Mar 30, 2009 at 07:11:18AM +0200, Björn Steinbrink wrote:\n> > On 2009.03.30 02:52:47 +0200, Johannes Schindelin wrote:\n> > > On Mon, 30 Mar 2009, Magnus Bäck wrote:\n> > > > On Friday, March 27, 2009 at 03:25 CET, Johannes Schindelin \n> > > > wrote:\n> > > > > On Thu, 26 Mar 2009, Magnus Bäck wrote:\n> > > > > > I'd be very surprised if ZwQueryDirectoryFile() hasn't always \n> > > > > > been around (I just verified ntdll.dll from NT 4.0), so that's \n> > > > > > not a worry. Don't know why MSDN reports it as introduced in \n> > > > > > XP.\n> > > > >\n> > > > > As the current maintainer of msysGit, I refuse to have something \n> > > > > in the installer I ship that relies on not-at-all guaranteed \n> > > > > interfaces.\n> > > > \n> > > > Although I do appreciate the importance of guaranteed interfaces, \n> > > > I am also pragmatic. An incompatible change in ntdll.dll would \n> > > > break vast amounts of programs, including cygwin. There is a lot \n> > > > to be said about Microsoft and their APIs, but I don't think they \n> > > > have a habit of changing ABIs or function semantics for userland \n> > > > libraries that have been around for 15 years.\n> > > \n> > > Had you pointed to some document that states that the function has \n> > > been in all NT-based versions, that would have done the trick.\n> > \n> > Not official documentation, but at least from some MS guy it seems: \n> > http://www.osronline.com/showThread.cfm?link=73086 (last message).\n> > \n> > Apparently, it was in NT3.x, but they document only what's actually \n> > defined in the header.\n> \n> How about runtime checking? You could do GetProcAddress(...) and if you \n> don't get it use the old behaviour. I mean if it really is faster why \n> not let Users of recent systems benefit from it.\n\nWhile my first reaction was negative, I have to admit that thinking about \nit longer, it does seem to make a whole lot of sense.\n\nThanks,\nDscho\n"},{"id":"110062","messageId":"20090331203248.GE27249@jeeves.jpl.local","threadId":"18447","inReplyTo":"alpine.DEB.1.00.0903310128410.10279@pacific.mpi-cbg.de","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Magnus Bäck","fromEmail":"baeck@swipnet.se","sentAt":"2009-03-31T20:32:48Z","receivedAt":"2009-03-31T20:32:48Z","isPatch":false,"sender":{"key":"baeck@swipnet.se","avatar":null},"body":"On Tuesday, March 31, 2009 at 01:29 CEST,\n Johannes Schindelin wrote:\n\n> On Tue, 31 Mar 2009, Heiko Voigt wrote:\n> \n> > On Mon, Mar 30, 2009 at 07:11:18AM +0200, Björn Steinbrink wrote:\n> >\n> > > Not official documentation, but at least from some MS guy it seems: \n> > > http://www.osronline.com/showThread.cfm?link=73086 (last message).\n> > > \n> > > Apparently, it was in NT3.x, but they document only what's actually \n> > > defined in the header.\n> > \n> > How about runtime checking? You could do GetProcAddress(...) and if\n> > you don't get it use the old behaviour. I mean if it really is\n> > faster why not let Users of recent systems benefit from it.\n> \n> While my first reaction was negative, I have to admit that thinking\n> about it longer, it does seem to make a whole lot of sense.\n\nIf anything worries me it's forward compatibility should Microsoft\nchange the function signature. Backwards compatibility can always\nbe guaranteed by using GetProcAddress(). Again, I would be very\nsurprised but IF it could be quite fatal.\n\nAnyway, we don't know for sure if it's faster or if it fixes the DST\nproblem of FindFirstFile(). I'll write some code to try it out.\n\n-- \nMagnus Bäck\nbaeck@swipnet.se\n"},{"id":"110066","messageId":"alpine.DEB.1.00.0903312249190.6616@intel-tinevez-2-302","threadId":"18447","inReplyTo":"20090331203248.GE27249@jeeves.jpl.local","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-31T20:49:48Z","receivedAt":"2009-03-31T20:49:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 31 Mar 2009, Magnus Bäck wrote:\n\n> On Tuesday, March 31, 2009 at 01:29 CEST,\n> Johannes Schindelin wrote:\n> \n> > On Tue, 31 Mar 2009, Heiko Voigt wrote:\n> > \n> > > On Mon, Mar 30, 2009 at 07:11:18AM +0200, Björn Steinbrink wrote:\n> > >\n> > > > Not official documentation, but at least from some MS guy it seems: \n> > > > http://www.osronline.com/showThread.cfm?link=73086 (last message).\n> > > > \n> > > > Apparently, it was in NT3.x, but they document only what's actually \n> > > > defined in the header.\n> > > \n> > > How about runtime checking? You could do GetProcAddress(...) and if\n> > > you don't get it use the old behaviour. I mean if it really is\n> > > faster why not let Users of recent systems benefit from it.\n> > \n> > While my first reaction was negative, I have to admit that thinking\n> > about it longer, it does seem to make a whole lot of sense.\n> \n> If anything worries me it's forward compatibility should Microsoft\n> change the function signature. Backwards compatibility can always\n> be guaranteed by using GetProcAddress(). Again, I would be very\n> surprised but IF it could be quite fatal.\n> \n> Anyway, we don't know for sure if it's faster or if it fixes the DST\n> problem of FindFirstFile(). I'll write some code to try it out.\n\nThank you very much, I appreciate it!\n\nCiao,\nDscho\n"},{"id":"110109","messageId":"544dda350904010228q93c7425m7ba12e2286617b3d@mail.gmail.com","threadId":"18447","inReplyTo":"20090321154738.GA27249@jeeves.jpl.local","subject":"Re: Implementing stat() with FindFirstFile()","fromName":"Nazri Ramliy","fromEmail":"ayiehere@gmail.com","sentAt":"2009-04-01T09:28:36Z","receivedAt":"2009-04-01T09:28:36Z","isPatch":false,"sender":{"key":"ayiehere@gmail.com","avatar":"https://avatars.githubusercontent.com/u/164756?v=4"},"body":"On Sat, Mar 21, 2009 at 11:47 PM, Magnus Bäck wrote:\n> Is there any reason why compat/win32.h uses GetFileAttributesEx()\n> instead of FindFirstFile() to implement the stat() call on Windows?\n\nThis blog post explains checking file existence using GetFileAttributes(Ex) vs.\nFindFirstFile quite nicely:\n\n http://blogs.msdn.com/oldnewthing/archive/2007/10/23/5612082.aspx\n\nnazri.\n"}]}