Jim Leonard wrote at about 16:55:04 -0500 on Monday, August 31, 2009: > Jeffrey J. Kosowsky wrote: > > The kludge is not the use per-se of hard links > > to store the file data but the resulting collapsing of multiple > > version of the same file to a single inode that correspond to > > different inodes and file attributes in the source data. > > You do not have a clear understanding of how hard links work. Hard > links don't store data; they represent a name that points to a single > inode. All files have at least one hard link (their original name). > When you add an additional hard link, it points to the same inode as the > original filename.
You have selectively cut & pasted my comments to prove your straw man argument. I understand *exactly* how hard links work. However, the problem here is that hard links are used to store files that have different attributes (e.g., timestamps, rwx attributes) on the same inode. This *never* happens in a normal filesystem since all files with the same inode in a normal fileystem must have the same attributes. Hence, a new construct (called the 'attrib' file) must be created to store the different timestamps and rwx attributes (and potentially in the future other attributes) for the different versions of the same file. In contrast, the normal usage of hard links uses a single inode to represent the same file albeit differing only in name. > Hard links were designed for this specific purpose (multiple names > pointing to the same file without the file data being replicated as > well) and their use is not a kludge -- in fact, BackupPC uses them > exactly for their intended purpose. But these are *not* the same files -- they just happen to have the same data. > For pooling identical files, this kind of thing could be either > maintained in the application itself (what you are proposing) or by the > filesystem (what BackupPC actually does). Each has tradeoffs, but doing > it via the filesystem is hardly "wrong" or a kludge. If you had read what I wrote rather than jumping to the conclusion that I did not understand hard links, you would have known that the "kludge" is caused by the collapsing of several truly non-identical files (though they have the same content) onto a single inode which requires the creation of a separate database (called the attib file) to store the timestamps and rwx attributes that are normally stored within the filesystem itself. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ 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/
