Folks,
just to dropping into this discussion.
Kern Sibbald wrote:
> 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")
This is right, but only part of a bigger problem. FreeBSD, as opposed to
other OSes allows symlinks to have own permissions ACL etc and offers
appropriate syscalls. Specifically this are lchmod, lutimes, lchflags
acs_set/get_link_np.
I have written a patch witch addresses this issue. So this patch will
interfere with my changes. I would prefer not to have above mentioned
"new feature" in the CVS since this will surely give me conflicts on
next "cvs update".
I'm in the process of writing the regression scripts for my patches.
Since my patch addresses other stuff (mostly ACL code, and some minor
fixes) and the writing of regression scripts isn't that well documented
this may take some time. Nonetheless I hope to have the testing done
until next Monday.
I will look into the other new patches this evening to see if they
interfere with my changes and report back tomorrow.
Attila
>>>> 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-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
>
>
-------------------------------------------------------------------------
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
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
