{"thread":{"id":"3090","subject":"[PATCH] \"sleep 1\" sleeps too little on cygwin","startedAt":"2006-01-17T11:25:37Z","lastAt":"2006-01-20T15:40:55Z","messageCount":22,"participants":["Alex Riesen","Junio C Hamano","Johannes Schindelin","Christopher Faylor"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"14778","messageId":"81b0412b0601170325y60094b4w693ac37490c67410@mail.gmail.com","threadId":"3090","inReplyTo":null,"subject":"[PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-17T11:25:37Z","receivedAt":"2006-01-17T11:25:37Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Probably another one windows quirk, or just the moon phases,\nbut I have to make damn sure it sleeps long enough.\n\n\ndiff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh\nindex e3ebf38..8c5b614 100755\n--- a/t/t4011-diff-symlink.sh\n+++ b/t/t4011-diff-symlink.sh\n@@ -56,10 +56,11 @@ cat > expected << EOF\n diff --git a/frotz b/frotz\n EOF\n \n+secs=\"$SECONDS\"\n+while [ \"$SECONDS\" = \"$secs\" ]; do sleep 1; done\n test_expect_success \\\n 'diff identical, but newly created symlink' \\\n- 'sleep 1 &&\n- ln -s xyzzy frotz &&\n+ 'ln -s xyzzy frotz &&\n git-diff-index -M -p $tree > current &&\n compare_diff_patch current expected'\n \n"},{"id":"14794","messageId":"7vvewi2typ.fsf@assigned-by-dhcp.cox.net","threadId":"3090","inReplyTo":"81b0412b0601170325y60094b4w693ac37490c67410@mail.gmail.com","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-18T01:41:34Z","receivedAt":"2006-01-18T01:41:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> Probably another one windows quirk, or just the moon phases,\n> but I have to make damn sure it sleeps long enough.\n\nIIRC, DOS file timestamps have 2 seconds granularity, so\nsleeping for one second might not be enough to begin with. Also\nI run my cygwin test on sufficiently slow machine, so that may\nexplain why I have not notice the problem ;-).\n\nInstead of depending on $SECONDS (isn't it a bashism?), how\nabout doing something like this?\n\n---\ndiff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh\nindex e3ebf38..9a5fa38 100755\n--- a/t/t4011-diff-symlink.sh\n+++ b/t/t4011-diff-symlink.sh\n@@ -23,6 +23,7 @@ EOF\n test_expect_success \\\n 'diff new symlink' \\\n 'ln -s xyzzy frotz &&\n+ touch -t 199901010000 frotz &&\n git-update-index &&\n tree=$(git-write-tree) &&\n git-update-index --add frotz &&\n@@ -58,8 +59,8 @@ EOF\n \n test_expect_success \\\n 'diff identical, but newly created symlink' \\\n- 'sleep 1 &&\n- ln -s xyzzy frotz &&\n+ 'ln -s xyzzy frotz &&\n+ touch -t 200201010000 frotz &&\n git-diff-index -M -p $tree > current &&\n compare_diff_patch current expected'\n \n"},{"id":"14799","messageId":"7vmzhtzzlf.fsf@assigned-by-dhcp.cox.net","threadId":"3090","inReplyTo":"81b0412b0601170325y60094b4w693ac37490c67410@mail.gmail.com","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-18T08:53:32Z","receivedAt":"2006-01-18T08:53:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sorry, but the previous patch turns out to be bogus as well.\n'touch' did not affect the timestamp of the symbolic link but\nended up creating a file pointed by it, and since we (hopefully)\ncorrectly do lstat() not stat(), it did not have any good\neffect. Here is an replacement.\n\n-- >8 --\nSubject: [PATCH] t4011: \"sleep 1\" sleeps too little on cygwin\n\nThis test depended on \"sleep 1\" not to return until the next\nsecond boundary, to get a dirty index entry. An initial fix was\nprovided by Alex Riesen using a bashism $SECONDS, but make it a\nbit more portable, and also work around a potential problem on a\nfilesystem with coarser-than-a-second timestamp granularity,\nthis patch fixes it a bit differently.\n\nThe test is checking if we correctly notice the stat changes,\nand the timestamp is not the only thing we have in the stat part\nof the index. This commit fixes the problem by leaving the\noriginal symlink we create on the filesystem, so that it keeps\nthe inode number used for the original symlink in use, and then\ncreate a second one which should get a different inode number.\n\nSigned-off-by: Junio C Hamano \n\n---\n\n t/t4011-diff-symlink.sh | 5 ++---\n 1 files changed, 2 insertions(+), 3 deletions(-)\n\n5f6849e7b60bc4908bf10a7946fd93d4aaaf9c35\ndiff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh\nindex e3ebf38..f0e3491 100755\n--- a/t/t4011-diff-symlink.sh\n+++ b/t/t4011-diff-symlink.sh\n@@ -48,7 +48,7 @@ EOF\n \n test_expect_success \\\n 'diff removed symlink' \\\n- 'rm frotz &&\n+ 'mv frotz nitfol &&\n git-diff-index -M -p $tree > current &&\n compare_diff_patch current expected'\n \n@@ -58,8 +58,7 @@ EOF\n \n test_expect_success \\\n 'diff identical, but newly created symlink' \\\n- 'sleep 1 &&\n- ln -s xyzzy frotz &&\n+ 'ln -s xyzzy frotz &&\n git-diff-index -M -p $tree > current &&\n compare_diff_patch current expected'\n \n-- \n1.1.3.gce7b\n"},{"id":"14803","messageId":"Pine.LNX.4.63.0601181233460.8678@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3090","inReplyTo":"7vmzhtzzlf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-01-18T11:35:08Z","receivedAt":"2006-01-18T11:35:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Jan 2006, Junio C Hamano wrote:\n\n> @@ -48,7 +48,7 @@ EOF\n> \n> test_expect_success \\\n> 'diff removed symlink' \\\n> - 'rm frotz &&\n> + 'mv frotz nitfol &&\n> git-diff-index -M -p $tree > current &&\n> compare_diff_patch current expected'\n> \n> @@ -58,8 +58,7 @@ EOF\n> \n> test_expect_success \\\n> 'diff identical, but newly created symlink' \\\n> - 'sleep 1 &&\n> - ln -s xyzzy frotz &&\n> + 'ln -s xyzzy frotz &&\n\nAnd where does the time lag (required for the test) come from now?\n\nCiao,\nDscho\n"},{"id":"14810","messageId":"81b0412b0601180550k4df9b89fwf73af7966095ffc7@mail.gmail.com","threadId":"3090","inReplyTo":"7vvewi2typ.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-18T13:50:04Z","receivedAt":"2006-01-18T13:50:04Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/18/06, Junio C Hamano wrote:\n> Instead of depending on $SECONDS (isn't it a bashism?), how\n> about doing something like this?\n\nProbably not, even QNX6 ksh has it, and being the most broken shell\nI ever met, I'd consider $SECONDS safe 8-)\n"},{"id":"14823","messageId":"7vd5ipzd9n.fsf@assigned-by-dhcp.cox.net","threadId":"3090","inReplyTo":"81b0412b0601180550k4df9b89fwf73af7966095ffc7@mail.gmail.com","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-18T16:55:48Z","receivedAt":"2006-01-18T16:55:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> On 1/18/06, Junio C Hamano wrote:\n>> Instead of depending on $SECONDS (isn't it a bashism?), how\n>> about doing something like this?\n>\n> Probably not, even QNX6 ksh has it, and being the most broken shell\n> I ever met, I'd consider $SECONDS safe 8-)\n\nWhen I have to answer these questions myself, I mostly do so by\nchecking http://www.opengroup.org/onlinepubs/009695399/.\n"},{"id":"14824","messageId":"7v4q41zd1t.fsf@assigned-by-dhcp.cox.net","threadId":"3090","inReplyTo":"Pine.LNX.4.63.0601181233460.8678@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-18T17:00:30Z","receivedAt":"2006-01-18T17:00:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> And where does the time lag (required for the test) come from now?\n\nThe point of the change is that it avoids to depend on the time\nlag. The test is to make sure we catch dirty index; instead of\ntimestamp difference it now uses i-num difference for that.\n"},{"id":"14841","messageId":"20060118185229.GA3001@steel.home","threadId":"3090","inReplyTo":"7v4q41zd1t.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-18T18:52:29Z","receivedAt":"2006-01-18T18:52:29Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Wed, Jan 18, 2006 18:00:30 +0100:\n> Johannes Schindelin writes:\n> \n> > And where does the time lag (required for the test) come from now?\n> \n> The point of the change is that it avoids to depend on the time\n> lag. The test is to make sure we catch dirty index; instead of\n> timestamp difference it now uses i-num difference for that.\n> \n\nthis is probable unsafe too: not all systems export inodes\n(the recent cygwin breakage comes to mind).\n"},{"id":"14862","messageId":"7vmzhtqakl.fsf@assigned-by-dhcp.cox.net","threadId":"3090","inReplyTo":"20060118185229.GA3001@steel.home","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-19T01:18:50Z","receivedAt":"2006-01-19T01:18:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> this is probable unsafe too: not all systems export inodes\n> (the recent cygwin breakage comes to mind).\n\nHmph. I thought that breakage was about struct dirent, not what\nwe read from struct stat; d_ino is XSI extension so that may\nhave been the reason cygwin folks removed it, but st_ino is in\nBASE --- did they remove that as well?\n\nBut you are right. Among \"struct stat\" members, only S_IFMT\npart from st_mode and st_size are meaningful for symlinks after\nlstat() and other members are unspecified. Which means that, in\nthe strictest sense, the original test that tried to see if the\ntimestamp change makes the entry for the symlink cache-dirty,\nwas pointless.\n\nHOWEVER.\n\nWe live in the real world, not in a strict POSIX world. We (the\nindex file) relies on lstat() to update st_mtime and/or st_ino,\nand I think it is OK (IOW, we declare that platforms on which we\ncannot rely on these members are not worth supporting).\n\n\nBy the way, if you have an access to git on cygwin with FAT,\ncould you test your patch ($SECONDS) and then i-num patch (the\nmachine with cygwin I can borrow has only NTFS) please?\n"},{"id":"14873","messageId":"20060119051848.GA8121@trixie.casa.cgf.cx","threadId":"3090","inReplyTo":"7vvewi2typ.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T05:18:48Z","receivedAt":"2006-01-19T05:18:48Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Tue, Jan 17, 2006 at 05:41:34PM -0800, Junio C Hamano wrote:\n>Alex Riesen writes:\n>>Probably another one windows quirk, or just the moon phases, but I have\n>>to make damn sure it sleeps long enough.\n>\n>IIRC, DOS file timestamps have 2 seconds granularity, so sleeping for\n>one second might not be enough to begin with. Also I run my cygwin\n>test on sufficiently slow machine, so that may explain why I have not\n>notice the problem ;-).\n\nCygwin really does sleep a second if you tell it to, but on FAT\nfilesystems, you're right, the granularity something like 2 seconds.\n\ncgf\n"},{"id":"14874","messageId":"20060119052043.GB8121@trixie.casa.cgf.cx","threadId":"3090","inReplyTo":"7vmzhtqakl.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T05:20:43Z","receivedAt":"2006-01-19T05:20:43Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Wed, Jan 18, 2006 at 05:18:50PM -0800, Junio C Hamano wrote:\n>Alex Riesen writes:\n>\n>> this is probable unsafe too: not all systems export inodes\n>> (the recent cygwin breakage comes to mind).\n>\n>Hmph. I thought that breakage was about struct dirent, not what\n>we read from struct stat; d_ino is XSI extension so that may\n>have been the reason cygwin folks removed it, but st_ino is in\n>BASE --- did they remove that as well?\n\nNo, we didn't. We (i.e., I) removed d_ino in cygwin because it couldn't\nbe reliably calculated without slowing things down. st_ino will always\nbe there.\n\ncgf\n"},{"id":"14896","messageId":"81b0412b0601190701g2696b1a9l14f3d288875e11ab@mail.gmail.com","threadId":"3090","inReplyTo":"7vmzhtqakl.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-19T15:01:19Z","receivedAt":"2006-01-19T15:01:19Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/19/06, Junio C Hamano wrote:\n> By the way, if you have an access to git on cygwin with FAT,\n> could you test your patch ($SECONDS) and then i-num patch (the\n> machine with cygwin I can borrow has only NTFS) please?\n\nWorks if sleep is for 2 secs (I completely forgot about that stupid\nFAT granularity!)\nst_ino is always the same (it is a hash of pathname).\nChristopher, how is that supposed to work with hardlinks? (NTFS has\nhardlinks, BTW)\n"},{"id":"14910","messageId":"7vr774dqjo.fsf@assigned-by-dhcp.cox.net","threadId":"3090","inReplyTo":"81b0412b0601190701g2696b1a9l14f3d288875e11ab@mail.gmail.com","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-19T18:24:27Z","receivedAt":"2006-01-19T18:24:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> Works if sleep is for 2 secs (I completely forgot about that stupid\n> FAT granularity!)\n> st_ino is always the same (it is a hash of pathname).\n> Christopher, how is that supposed to work with hardlinks? (NTFS has\n> hardlinks, BTW)\n\nSo the verdict is to take your patch but wait for three seconds?\nI still have mild aversion about $SECONDS though...\n"},{"id":"14912","messageId":"20060119182822.GA32022@trixie.casa.cgf.cx","threadId":"3090","inReplyTo":"81b0412b0601190701g2696b1a9l14f3d288875e11ab@mail.gmail.com","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T18:28:22Z","receivedAt":"2006-01-19T18:28:22Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 04:01:19PM +0100, Alex Riesen wrote:\n>On 1/19/06, Junio C Hamano wrote:\n>> By the way, if you have an access to git on cygwin with FAT,\n>> could you test your patch ($SECONDS) and then i-num patch (the\n>> machine with cygwin I can borrow has only NTFS) please?\n>\n>Works if sleep is for 2 secs (I completely forgot about that stupid\n>FAT granularity!)\n>st_ino is always the same (it is a hash of pathname).\n>Christopher, how is that supposed to work with hardlinks? (NTFS has\n>hardlinks, BTW)\n\nThere is OS support hardlinks work on NTFS/NT but not on FAT*\n\"filesystems\" or Windows 9x variants. Hardlink support on Cygwin\nmirrors this.\n\ncgf\n"},{"id":"14925","messageId":"20060119221227.GB3601@steel.home","threadId":"3090","inReplyTo":"20060119182822.GA32022@trixie.casa.cgf.cx","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-19T22:12:27Z","receivedAt":"2006-01-19T22:12:27Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Christopher Faylor, Thu, Jan 19, 2006 19:28:22 +0100:\n> >> By the way, if you have an access to git on cygwin with FAT,\n> >> could you test your patch ($SECONDS) and then i-num patch (the\n> >> machine with cygwin I can borrow has only NTFS) please?\n> >\n> >Works if sleep is for 2 secs (I completely forgot about that stupid\n> >FAT granularity!)\n> >st_ino is always the same (it is a hash of pathname).\n> >Christopher, how is that supposed to work with hardlinks? (NTFS has\n> >hardlinks, BTW)\n> \n> There is OS support hardlinks work on NTFS/NT but not on FAT*\n> \"filesystems\" or Windows 9x variants. Hardlink support on Cygwin\n> mirrors this.\n> \n\nNo, I rephrase the question: how does the method of calculating\n.st_ino from pathname handles hardlinked files on NTFS?\nBy briefly looking at the code it does not seem to be possible.\n"},{"id":"14926","messageId":"20060119221346.GC3601@steel.home","threadId":"3090","inReplyTo":"7vr774dqjo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-19T22:13:46Z","receivedAt":"2006-01-19T22:13:46Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Thu, Jan 19, 2006 19:24:27 +0100:\n> \n> > Works if sleep is for 2 secs (I completely forgot about that stupid\n> > FAT granularity!)\n> > st_ino is always the same (it is a hash of pathname).\n> > Christopher, how is that supposed to work with hardlinks? (NTFS has\n> > hardlinks, BTW)\n> \n> So the verdict is to take your patch but wait for three seconds?\n> I still have mild aversion about $SECONDS though...\n> \n\nMaybe just wait for 3 (three) seconds? It should guarantee the change\nin mtime.\n"},{"id":"14928","messageId":"20060119222553.GB7567@trixie.casa.cgf.cx","threadId":"3090","inReplyTo":"20060119221227.GB3601@steel.home","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-19T22:25:53Z","receivedAt":"2006-01-19T22:25:53Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 11:12:27PM +0100, Alex Riesen wrote:\n>Christopher Faylor, Thu, Jan 19, 2006 19:28:22 +0100:\n>>>>By the way, if you have an access to git on cygwin with FAT, could you\n>>>>test your patch ($SECONDS) and then i-num patch (the machine with\n>>>>cygwin I can borrow has only NTFS) please?\n>>>\n>>>Works if sleep is for 2 secs (I completely forgot about that stupid FAT\n>>>granularity!) st_ino is always the same (it is a hash of pathname).\n>>>Christopher, how is that supposed to work with hardlinks? (NTFS has\n>>>hardlinks, BTW)\n>>\n>>There is OS support hardlinks work on NTFS/NT but not on FAT*\n>>\"filesystems\" or Windows 9x variants. Hardlink support on Cygwin\n>>mirrors this.\n>\n>No, I rephrase the question: how does the method of calculating .st_ino\n>from pathname handles hardlinked files on NTFS? By briefly looking at\n>the code it does not seem to be possible.\n\nCygwin doesn't create an inode from the path name on NTFS. NT gives you\na 64 bit unique number which identifies a file so we use that. That\nmeans that the inodes of hardlinked files should be the same, just like\non linux.\n\nInodes are only calculated by hashing the path name when the OS lacks\nthe support to provide a \"real\" inode and in that case there is no hard\nlink support available so it's a non-issue.\n\ncgf\n"},{"id":"14932","messageId":"7vbqy78zwy.fsf@assigned-by-dhcp.cox.net","threadId":"3090","inReplyTo":"20060119222553.GB7567@trixie.casa.cgf.cx","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-20T01:13:17Z","receivedAt":"2006-01-20T01:13:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christopher Faylor writes:\n\n> Inodes are only calculated by hashing the path name when the OS lacks\n> the support to provide a \"real\" inode and in that case there is no hard\n> link support available so it's a non-issue.\n\nDoes that mean on such filesystems \"mv foo bar\" would change the\ni-num of the moved entity?\n\nI am not complaining even if that is the case. I just want to\nunderstand what it does.\n"},{"id":"14931","messageId":"7v64of8zwn.fsf@assigned-by-dhcp.cox.net","threadId":"3090","inReplyTo":"20060119221346.GC3601@steel.home","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-20T01:13:28Z","receivedAt":"2006-01-20T01:13:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> Maybe just wait for 3 (three) seconds? It should guarantee the change\n> in mtime.\n\nThat is certainly an easy way out. Unless somebody comes up\nwith more simple and elegant solution I'd opt for this.\n"},{"id":"14937","messageId":"20060120033548.GE5090@trixie.casa.cgf.cx","threadId":"3090","inReplyTo":"7vbqy78zwy.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-20T03:35:49Z","receivedAt":"2006-01-20T03:35:49Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Thu, Jan 19, 2006 at 05:13:17PM -0800, Junio C Hamano wrote:\n>Christopher Faylor writes:\n>>Inodes are only calculated by hashing the path name when the OS lacks\n>>the support to provide a \"real\" inode and in that case there is no hard\n>>link support available so it's a non-issue.\n>\n>Does that mean on such filesystems \"mv foo bar\" would change the i-num\n>of the moved entity?\n\nI just tried this on Windows XP. On a FAT32 or a NTFS filesystem the\ninode is unchanged. On a FAT filesystem, it changes. I assume that\nmeans that FAT doesn't support a real file ID. The only thing I think\nanyone would be using FAT for these days is possibly a boot partition.\nThat's the only reason I have one. I use to to multi-boot various\nflavors of Windows. It's the lowest common denominator.\n\n>I am not complaining even if that is the case. I just want to\n>understand what it does.\n\nNP. I complain about this fairly frequently myself. :-)\n\ncgf\n"},{"id":"14952","messageId":"81b0412b0601200723k1a271046u9c310d9c9b7d83f0@mail.gmail.com","threadId":"3090","inReplyTo":"20060120033548.GE5090@trixie.casa.cgf.cx","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-01-20T15:23:10Z","receivedAt":"2006-01-20T15:23:10Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/20/06, Christopher Faylor wrote:\n> On Thu, Jan 19, 2006 at 05:13:17PM -0800, Junio C Hamano wrote:\n> >Christopher Faylor writes:\n> >>Inodes are only calculated by hashing the path name when the OS lacks\n> >>the support to provide a \"real\" inode and in that case there is no hard\n> >>link support available so it's a non-issue.\n> >\n> >Does that mean on such filesystems \"mv foo bar\" would change the i-num\n> >of the moved entity?\n\nIt is just a rename. It will not change inode by definition (the file is the\nsame, it is the name which was changed). To get inode change you\nhave to create it, like \"cp foo bar; rm foo\". And now, if a filesystem\nhas (or exports) inodes, would the inode change. If it does not, you\nreally can't say anything about the inode (it can even change, and\ndoes in this case, being calculated from pathname).\n\n> I just tried this on Windows XP. On a FAT32 or a NTFS filesystem the\n\nI have FAT32. It does not support inodes\"\n $ : > foo\n $ stat foo |grep node\n Device: 111712fch/286724860d Inode: 3595119992080318288 Links: 1\n $ mv foo bar\n $ stat bar |grep node\n Device: 111712fch/286724860d Inode: 3595119974866484701 Links: 1\n\n> inode is unchanged. On a FAT filesystem, it changes. I assume that\n> means that FAT doesn't support a real file ID. The only thing I think\n> anyone would be using FAT for these days is possibly a boot partition.\n\nIt's still faster than NTFS, I use it as a temporary compilation partition,\nand as NT is painfully slow about filesystems and throughput in general,\nI keep my sources on the partition as well.\n\n> That's the only reason I have one. I use to to multi-boot various\n> flavors of Windows. It's the lowest common denominator.\n\nLowliest.\n"},{"id":"14953","messageId":"20060120154054.GA3392@trixie.casa.cgf.cx","threadId":"3090","inReplyTo":"81b0412b0601200723k1a271046u9c310d9c9b7d83f0@mail.gmail.com","subject":"Re: [PATCH] \"sleep 1\" sleeps too little on cygwin","fromName":"Christopher Faylor","fromEmail":"me@cgf.cx","sentAt":"2006-01-20T15:40:55Z","receivedAt":"2006-01-20T15:40:55Z","isPatch":true,"sender":{"key":"me@cgf.cx","avatar":null},"body":"On Fri, Jan 20, 2006 at 04:23:10PM +0100, Alex Riesen wrote:\n>On 1/20/06, Christopher Faylor wrote:\n>> On Thu, Jan 19, 2006 at 05:13:17PM -0800, Junio C Hamano wrote:\n>> >Christopher Faylor writes:\n>> >>Inodes are only calculated by hashing the path name when the OS lacks\n>> >>the support to provide a \"real\" inode and in that case there is no hard\n>> >>link support available so it's a non-issue.\n>> >\n>> >Does that mean on such filesystems \"mv foo bar\" would change the i-num\n>> >of the moved entity?\n>\n>It is just a rename. It will not change inode by definition (the file is the\n>same, it is the name which was changed). To get inode change you\n>have to create it, like \"cp foo bar; rm foo\". And now, if a filesystem\n>has (or exports) inodes, would the inode change. If it does not, you\n>really can't say anything about the inode (it can even change, and\n>does in this case, being calculated from pathname).\n>\n>> I just tried this on Windows XP. On a FAT32 or a NTFS filesystem the\n>\n>I have FAT32. It does not support inodes\"\n> $ : > foo\n> $ stat foo |grep node\n> Device: 111712fch/286724860d Inode: 3595119992080318288 Links: 1\n> $ mv foo bar\n> $ stat bar |grep node\n> Device: 111712fch/286724860d Inode: 3595119974866484701 Links: 1\n\nOk, I must have been hallucinating. I just tried it again. It doesn't\nwork on FAT32.\n\ncgf\n"}]}