On Wednesday 13 December 2006 08:49, Oliver Lehmann wrote:
a> Kern Sibbald writes:
>
> >>
> >> patch-src-findlib-attribs.c
> >> when restoring a symlink, use lchflags to restore the file flags
> >> defined for the symlink ("new feature")
> >> when restoring a hardlink, don't call chmod, chown, utime because it is
> >> a hardlink and don't have such attributes (as far as I know, if
someone
> >> with more FS-foo can step up and confirm this?). Changing this
> >> attributes will change the sourcefiles attributes which is probably not
> >> what is wanted here anyway....
> >
> > I'll have to think about this a bit more. However, I don't think it is
> > correct to skip setting the attributes. To understand hardlinks, the
first
> > thing is to realize that the name is slightly misleading. A hard link is
not
> > really a link. The data for the two files the attributes are one and the
> > same. The situation is very different from a softlink where there is a
> > separate directory entry that "points" to an existing file.
> >
> > Thus to properly restore a hardlink you must also reset the attributes or
you
> > could potentially end up with incorrect attributes (owner, modes, ...).
>
> Ok, but from my understanding setting attributes on a hardlink changes the
> attributes of the inode the hardlink is pointing to, like for "normal" files
> which are technically hardlinks too.
There is no such think as a hardlink. There is a hardlink operation. It is
very different from a softlink, and if you think about them the same way, you
will never get it right. Two files that are hardlinked (really poor
terminology) *are* one and the same file. The two files share the same
inode, so there is no "hardlink" with separate attributes that points to an
inode (as is the case for a softlink, which is a pointer). For hardlinked
files, there is only one set of data and one set of attributes.
> So changing attributes for n "objects"
> pointing to the same inode is like changing the attributes n times for the
> same object or is this wrong?
There are n filenames that share the same data and attributes true, and if you
are doing a full restore, it is possible Bacula will set those attributes to
the same thing n times since each of Bacula's n representations of the
hardlinked files contains the attributes (there is only one copy of the data
though). Ideally, Bacula would set the attributes only once when it restores
the data, but I would have to look at the code (which I don't have the time
to do) to remember exactly what Bacula does.
> If you think attributes for hardlinks have to be restored as well, the fix
> for src/findlib/attribs.c has to be redone. I can do so but I still
> think.... ;)
Ideally as I mentioned above, the attributes are only kept with the data and
thus are only set one time. Then when a second filename is found it would
simply be hardlinked to the first file (i.e. become one and the same) and it
would not then be necessary to re-set the attributes. If this is what your
patch does, then it is probably OK. If not, we need to re-think it. In any
case, this could be a rather fundamental change to how the low level part of
Bacula works, and I am a bit worried about trying to include it in version
1.40.0.
Regards,
Kern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
