Thread: win32 inode fix
For community review and application to HEAD; minor patch. Under Win32, stat() returns an st_ino field, but it has no meaning (on Win2K, and possibly all Win32 variants, it is always 0). This causes a number of problems in the dfmgr.c logic, which basically all revolve around the fact that *any* two files will appear to have the same inode. Note also that this solves the current issues related to initdb under Win32. --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
Attachment
Claudio Natoli <claudio.natoli@memetrics.com> 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?
-Neil (who knows next to nothing about Win32, so take that with a
grain of salt)
> Claudio Natoli <claudio.natoli@memetrics.com> 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? //mha
Magnus Hagander wrote: > > Claudio Natoli <claudio.natoli@memetrics.com> 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? 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 pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: > In reading the patch, it seems he is only doing "zero equals > unknown" on Win32, so I think we are fine. That's what I was trying to avoid: where possible, we shouldn't introduce platform-dependent #ifdefs IMHO. -Neil
Neil Conway wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > In reading the patch, it seems he is only doing "zero equals > > unknown" on Win32, so I think we are fine. > > That's what I was trying to avoid: where possible, we shouldn't > introduce platform-dependent #ifdefs IMHO. But the platform doesn't give us what we want so I don't see why we should weaken other platforms just for consistency. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: >Neil Conway wrote: > > >>Bruce Momjian <pgman@candle.pha.pa.us> writes: >> >> >>>In reading the patch, it seems he is only doing "zero equals >>>unknown" on Win32, so I think we are fine. >>> >>> >>That's what I was trying to avoid: where possible, we shouldn't >>introduce platform-dependent #ifdefs IMHO. >> >> > >But the platform doesn't give us what we want so I don't see why we >should weaken other platforms just for consistency. > > Surely the operative words are "where possible". Looks like this is one case where it is not reasonably possible. I don't think we will ever be totally rid of them. I tried quite hard to keep them to a minimum in initdb, but eliminating them was not really an option. cheers andrew
Patch applied. Thanks. --------------------------------------------------------------------------- Claudio Natoli wrote: > > For community review and application to HEAD; minor patch. > > Under Win32, stat() returns an st_ino field, but it has no meaning (on > Win2K, and possibly all Win32 variants, it is always 0). This causes a > number of problems in the dfmgr.c logic, which basically all revolve around > the fact that *any* two files will appear to have the same inode. > > Note also that this solves the current issues related to initdb under Win32. > > > --- > Certain disclaimers and policies apply to all email sent from Memetrics. > For the full text of these disclaimers and policies see > <a > href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em > ailpolicy.html</a> > > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073