Mirroring hard links. (was Re: Hamm frozen, Slink created)
If there were some way for ftp to do a df on the target machine, the
device layout could be integrated into the path array, making all inode
numbers unique. It's not clear to me that this ability would be provided
on every ftp site. However, like lR files, the mirrored site could keep a
df listing in a similar place for the use of the mirror program.
Seems to me the complex part comes when you "re-map" the target machine's
inodes to the local one, as the local machine is not likely to have the
same device structure. In fact, if most folks are like me, that local
mirror resides on one partition. Yet, I can see special cases, like where
you wish to keep contrib and non-free on a seperate partition from main.
This has turned into quite an "interesting" design problem. I'm not sure
it is cost effective to actually try to impliment it for mirror, but
mirror would become much more robust as a result. I just wish I had a
clone of myself that didn't want to go off and build space ships or
something ;-)
Waiting is,
Dwarf
--
Still sigless
On Fri, 27 Mar 1998, Philippe Troin wrote:
>
> On Thu, 26 Mar 1998 18:33:47 EST Dale Scheetz (dwarf@polaris.net)
> wrote:
>
> > On Thu, 26 Mar 1998, Raul Miller wrote:
> >
> > > Dale Scheetz <dwarf@polaris.net> wrote:
> > > > What keeps mirror from recognizing the hardness of the link and
> > > > reproducing the hard link in the local directory? I'm not suggesting
> > > > that mirror is currently capable of this, just trying to figure out
> > > > why it couldn't be.
> > >
> > > There's no way to distinguish between a copied file and a hardlinked
> > > file, without enhancing ftp. Thus, all files must be downloaded
> > > (and md5sums compared -- presumably you maintain a sorted list
> > > of md5s during download) to implement this. With symlinks, you
> > > can avoid the redundant downloads.
> > >
> > I take this to mean that currently ftp has no way to determine the inode
> > of a file on the remote machine? That would certainly make it hard to
> > impliment anything on the other end ;-)
> >
> > Still, if the directories containing hard links could be identified for
> > mirror, then it could simply read the directory and create the hard links
> > in the target directory. (just dreaming)
>
> You can get the inode number of any file with ftp.
>
> ftp> ls -i
>
> And build a inode num to file map or array.
>
> There's still a problem, you need a pair of inode/device to sort stuff out
> and you magic mirroring program might create "hard links" between two
> unrelated files which have the same inode number on different devices.
> Similarly, on the receiving machine if the mirror area has mounted
> fs, the link() might fail (in which case you could fall back on a
> symlink).
>
> Unless we require mirrors to be contained within the same fs OR that
> mount points are clearly marked (eg. we could detect mount points with
> a lost+found directory).
>
> Phil.
>
>
>
>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: