On 30 April 2002 11:40, Keith Owens wrote:
> On Tue, 30 Apr 2002 23:15:23 +1000,
> john slee <indigoid@higherplane.net> wrote:
> >probably because there is software out there relying on them being
> >numbers and being able to do 'if(inum_a == inum_b) { same_file(); }'
> >as appropriate. i can't think of a use for such a construct other than
> >preserving hardlinks in archives (does tar do this?) but i'm sure there
> >are others
>
> Any program that tries to preserve or detect hard links. cp, mv (files
> a and b are the same file). tar, cpio, rsync -H, du, etc.
>
> The assumption that inode numbers are unique within a mount point is
> one of the reasons that NFS export does not cross mount points by
> default. man exports, look for 'nohide'.
And I recently moved my /usr/src to separate partition.
That is, /usr/src is now a mount point.
I have to export it in NFS exports *and* mount it *on every workstation*
(potentially thousands of wks!).
I'll repeat myself. What if some advanced fs has no sensible way of
generating inode? Does it have to 'fake' it, just like [v]fat does it now?
(Yes, vfat is not 'advanced' fs, let's not discuss it...)
The fact that minix,ext[23],etc has inode #s is an *implementation detail*.
Historically entrenched in Unix.
Bad:
inum_a = inode_num(file1);
inum_b = inode_num(file2);
if(inum_a == inum_b) { same_file(); }
Better:
if(is_hardlinked(file1,file2) { same_file(); }
Yes, new syscal, blah, blah, blah... Not worth the effort, etc...
lets start a flamewar...
-- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:12 EST