On 3 May 2002 12:48, Rob Landley wrote:
> > 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...
>
> If I'm backing up a million files off of a big server, I don't want an
> enormous loop checking each and every one of them against each and every
> other one of them via some system call (potentially through the network) to
> go looking for dupes. I want some kind of index I can hash against on MY
> side of the wire to go "Have I seen this guy before?".
You can check pairs of files with same size,mode,etc and with hardlink
count>1. That will dramatically reduce number of is_hardlinked() calls
(unless you construct a pathological case of 1000000 hardlinks to
single file).
> That's EXACTLY what an inode is: a unique index for each file that can be
> compared to see if two directory entries refer to the same actual file.
> (Anything ELSE an inode is is an implementation detail, sure.)
>
> These kind of numeric identifiers show up all over the place. Process ids,
> user ids, filehandles... It's not an implementation detail, it's a sane
> API.
[snip]
I agree. API is not insane, but I wouldn't call it wonderful too.
-- 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:23 EST