Magnus Hagander wrote: > > Claudio Natoli <[EMAIL PROTECTED]> writes: > > > Under Win32, stat() returns an st_ino field, but it has no > > meaning (on > > > Win2K, and possibly all Win32 variants, it is always 0). > > > > MSDN says: > > > > Number of the information node (the inode) for the file > > (UNIX-specific). On UNIX file systems, the inode describes the > > file date and time stamps, permissions, and content. When files > > are hard-linked to one another, they share the same inode. The > > inode, and therefore st_ino, has no meaning in the FAT, HPFS, or > > NTFS file systems. > > > > I wonder if this might return non-zero for some relatively > > rare Win32 filesystems (say, an NFS share mounted via MS > > Services For Unix). Perhaps it might be cleaner to consider a > > zero inode "unknown", and therefore not equal to anything else? > > It still returns 0 on a NFS share mounted with SFU (just tested). My bet > is that it will always return 0. > > Might still be cleaner to change the code to make "zero equals unknown". > Is there a risk of another filesystem om some platform that won't return > inode?
Advertising
In reading the patch, it seems he is only doing "zero equals unknown" on Win32, so I think we are fine. We should continue using the inode on Unix platforms. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
