Yes, but they are obviously emulated by the cygwin1.dll.I just found a strange problem when using find on a FAT drive. I got: "find: .\tmp changed during execution of find"
OK, I analyzed the problem a bit and found that lstat can give different inode numbers on fat, see the attached testcase.
Structurally, FAT does not have inodes or hard links.
Did you try that? Look: (FAT drive)(snip) So for instance "tmp" and "tmp/." are different objects, not merely different directory entries pointing at the same inode as they would be in a UNIX-like filesystem.
By the way, you can investigate inode numbers using the -i option of ls instead of hacking up your own C program. $ ls -din tmp tmp/.
$ ls -ldin tmp tmp/. 2919335057 drwxr-xr-x 4 1006 513 0 Mar 10 13:06 tmp/ 2919335057 drwxr-xr-x 4 1006 513 0 Mar 10 13:06 tmp/./
Looks pretty similar to me, but I was looking for the following:
$ ls -ldin .\\tmp ./tmp 2919335057 drwxr-xr-x 4 1006 513 0 Mar 10 13:06 ./tmp/ 2805415844195 drwxr-xr-x 4 1006 513 0 Mar 10 13:06 .\tmp/
I came to that "program" by reducing the find soure to the bare minimum to show that problem.
So again, is this an expected/tolerated behaviour?
I know this is patchable in the find source, don't use inodes on FAT or network shares, but I guess this might be a small problem in the cygwin dll. Without promising anything I could use a pointer where to start digging into cygwin to find this problem ;)
Volker
-- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
