Joe Krahn wrote:
>
> As for problems with mapping inodes, I don't see how that is any worse
> than filename lists. In fact, contents are more likely to change with a
> filename reference than by an inode reference.
At least if you link by name, even if the contents are replaced you'll
end up linked to something that is probably somehow related to what you
expected. If you make a table of inode numbers, then something removes
some files and replaces them even with files of the same names and
contents there would not be much reason to expect the numbers in your
table to still reference the right files.
> The remote system could
> create temporary files for outstanding links (maybe named by the remote
> inode), to hold an inode reference even if the other files got deleted.
I'd expect the contents to come along with the first reference. But,
suppose your source filesystem is live and changing, and someone starts
two or more instances of rsync copying to the same destination at once
and they scramble each other's views of the inode numbers - or any other
similar activity happens on the destination side. If that sort of thing
never happened, we wouldn't need to be doing all these backups...
--
Les Mikesell
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
