Skip site navigation (1) Skip section navigation (2)

Re: win32 inode fix

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Neil Conway" <neilc(at)samurai(dot)com>,"Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: win32 inode fix
Date: 2004-02-09 12:21:18
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE1715D6@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-patches
> 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?

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

Responses

pgsql-patches by date

Next:From: Mark Cave-AylandDate: 2004-02-09 14:28:22
Subject: Re: ANALYZE patch for review
Previous:From: Andrew DunstanDate: 2004-02-09 07:05:02
Subject: Re: [HACKERS] dollar quoting

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group