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>

Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)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)

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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073