From: Alex Riesen Date: Fri, 20 Jan 2006 15:23:10 GMT Subject: Re: [PATCH] "sleep 1" sleeps too little on cygwin Message-ID: <81b0412b0601200723k1a271046u9c310d9c9b7d83f0@mail.gmail.com> In-Reply-To: <20060120033548.GE5090@trixie.casa.cgf.cx> On 1/20/06, Christopher Faylor wrote: > On Thu, Jan 19, 2006 at 05:13:17PM -0800, Junio C Hamano wrote: > >Christopher Faylor writes: > >>Inodes are only calculated by hashing the path name when the OS lacks > >>the support to provide a "real" inode and in that case there is no hard > >>link support available so it's a non-issue. > > > >Does that mean on such filesystems "mv foo bar" would change the i-num > >of the moved entity? It is just a rename. It will not change inode by definition (the file is the same, it is the name which was changed). To get inode change you have to create it, like "cp foo bar; rm foo". And now, if a filesystem has (or exports) inodes, would the inode change. If it does not, you really can't say anything about the inode (it can even change, and does in this case, being calculated from pathname). > I just tried this on Windows XP. On a FAT32 or a NTFS filesystem the I have FAT32. It does not support inodes" $ : > foo $ stat foo |grep node Device: 111712fch/286724860d Inode: 3595119992080318288 Links: 1 $ mv foo bar $ stat bar |grep node Device: 111712fch/286724860d Inode: 3595119974866484701 Links: 1 > inode is unchanged. On a FAT filesystem, it changes. I assume that > means that FAT doesn't support a real file ID. The only thing I think > anyone would be using FAT for these days is possibly a boot partition. It's still faster than NTFS, I use it as a temporary compilation partition, and as NT is painfully slow about filesystems and throughput in general, I keep my sources on the partition as well. > That's the only reason I have one. I use to to multi-boot various > flavors of Windows. It's the lowest common denominator. Lowliest.