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 AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/