On Wednesday 13 December 2006 16:07, Attila Fülöp wrote:
> 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.
I would be very happy if you will provide a patch. However, there is almost
zero chance that it will go in before 1.40.0 is released. The only fixes
that I am accepting at the moment are important bug fixes that do not disrupt
the code too much. I suggest you simply pull down the new file after I have
integrated the patch and adjust your code to work with it. This is,
unfortunately, something that developers must do quite often.
Concerning all these differences on FreeBSD: if the changes needed to make
things work correctly on FreeBSD are extensive and require a bit of
#ifdefing, we are going to have to re-think how we do it. The code is
already a bit messy and adding more non-standard system dependent code will
push it over my tolerance of messyness. As a consequence, we will need to
look at ways of making it cleaner --- e.g. moving some of the code, possibly
the system dependent code into subroutines ...
>
> 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-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
