Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
On Wednesday 13 December 2006 18:29, Attila Fülöp wrote:
> Kern Sibbald wrote:
> > 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.
>
> Yes, I know. We already talked about this.
>
> > 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.
>
> Well that is actually what I was trying to avoid, but such is life ;-).
>
> > 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 ...
>
> No, I don't think they are extensive. Just a couple of lines, mainly
> ifdefing chmod/chflags/utime to the 'l' versions.
>
> Sorry I don't have access to the current code right now, since it
> is at home. I will send you a 'preliminary patch' tomorrow, so You
> can peek at it and decide if it is too messy.
>
OK, thanks.
... [snip]
-
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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Jeremy C. Reed wrote: > On Wed, 13 Dec 2006, Kern Sibbald wrote: > >> 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 > ... > > I just want to point out that this problem is not specific to FreeBSD. I > am sure it will happen on many other (even non-BSD) operating systems too > ... but it just hasn't been reported yet. > > Linux with standard ext2fs file system has the same behaviour: you can not > create a link (hardlink) to target file that has the immutable file > attribute. (This is easy to try.) > > I am not familiar with this in Bacula though ... from a quick search > through bacula/src I don't see any ioctl for setting ext2fs flags. If I am > overlooking this, please point me to it. Sorry for the missunderstandig. I was refering to the symlink behaviour. This is specific to Free/NetBSD AFAIK. At least there is no lchmod(2) for any other OS I know of. > I am curious about this since file system flags are handled for BSD > systems, so why not others too? (If it does, please point me to it.) > > The standard e2fsprogs suite provides source code for this. See > lib/e2p/fsetflags.c and lib/e2p/fgetflags.c. This e2fsprogs code supports > both Linux ext2fs and BSD (chflags and stat). I assume xfsprogs and > progreiserfs have similar functionality and routines. > > So what I am getting at ... instead of just ifdef'ing for HAVE_CHFLAGS, > maybe it should have a common routines like fsetflags() and fgetflags() > that can be adjusted for all. > > - > 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 > > - 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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Kern Sibbald wrote:
> 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.
Yes, I know. We already talked about this.
> 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.
Well that is actually what I was trying to avoid, but such is life ;-).
> 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 ...
No, I don't think they are extensive. Just a couple of lines, mainly
ifdefing chmod/chflags/utime to the 'l' versions.
Sorry I don't have access to the current code right now, since it
is at home. I will send you a 'preliminary patch' tomorrow, so You
can peek at it and decide if it is too messy.
>> 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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Kern Sibbald wrote: > I encourage you to re-submit a patch for the above problem once 1.40.0 is > out, > possibly coordinating with Attila, since he seems to be working on something > a bit more encompasing (attribs + ACLs, ...). Ok, no problem - I'll do so. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ - 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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
On Wednesday 13 December 2006 17:20, Oliver Lehmann wrote:
> Jeremy C. Reed wrote:
>
>
> > Why do the chflags(attr->olname, s.st_flags) "restore the fileflags of the
> > sourcefile" twice?
>
> once in case the 2nd linking failed (there is a return after that!)
> and the 2nd time for the "linking was successfull" case.
>
>
> > Also the first reset of the chflags() should probably have error checking
> > and debugging there too (specific for that). (That's what I have added to
> > my own code.)
>
> The first chflags has error checking and reporting (rest file flags to
> none)
>Qmsg2(jcr, M_ERROR, 0, _("Could not reset file flags for file %s:
ERR=%s\n"),
>
> The second chflags has error checking and reporting as well (restore file
> flags in case of 2nd linking failed too and return)
>Qmsg2(jcr, M_ERROR, 0, _("Could not restore file flags for file %s:
ERR=%s\n"),
>
> The third chflags has error checking and reporting as well (restore file
> flags in case of linking was successfull)
>Qmsg2(jcr, M_ERROR, 0, _("Could not restore file flags for file %s:
ERR=%s\n"),
>
>
> > A hardlink is just a normal file -- it does have mode, ownership and
> > access and modification times. (I think maybe you just typed wrong word
> > above and didn't mean that.)
>
> Better say a normal/regular file is just another hardlink ;)
> All hardlinks/normal/regular files/whatever pointing to the same inode. This
> is why all hardlinks share the same attributes. Attributes are along with
other
> file informations stored inside the inode. -> all hardlinks same attributes.
> Thats why I said that setting attributes for, you might say the same inode,
> more than once doesn't need to be. That was why I changed set_attributes()
> to not set the attributes again when the filetype is FT_LNKSAVED because
then
> there is another file pointing to the same inode, already in the filesystem
> or has been restored before (otherwise the link() call in create_file would
> have failed). In the first case setting the attributes would be even wrong.
> In the second case it would not harm to set the attributes once more if
there
> wouldn't be such file flags like schg which are preventing this.
I encourage you to re-submit a patch for the above problem once 1.40.0 is out,
possibly coordinating with Attila, since he seems to be working on something
a bit more encompasing (attribs + ACLs, ...).
>
> >
> > Also a symlink has a mode (which can be changed but probably on all BSDs
> > it isn't even honored), ownership and modification time (time of symlink
> > creation) and change time (time of last file status change). I can see all
> > of this easily.
>
> A Symlink can have its own attributs which can be set too (lchmod(),
lchown(),
> lutimes()), this is right because it has an own inode to store the
information.
>
>
>
> --
> Oliver Lehmann
> http://www.pofo.de/
> http://wishlist.ans-netz.de/
>
> -
> 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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
On Wed, 13 Dec 2006, Kern Sibbald wrote: > 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 ... I just want to point out that this problem is not specific to FreeBSD. I am sure it will happen on many other (even non-BSD) operating systems too ... but it just hasn't been reported yet. Linux with standard ext2fs file system has the same behaviour: you can not create a link (hardlink) to target file that has the immutable file attribute. (This is easy to try.) I am not familiar with this in Bacula though ... from a quick search through bacula/src I don't see any ioctl for setting ext2fs flags. If I am overlooking this, please point me to it. I am curious about this since file system flags are handled for BSD systems, so why not others too? (If it does, please point me to it.) The standard e2fsprogs suite provides source code for this. See lib/e2p/fsetflags.c and lib/e2p/fgetflags.c. This e2fsprogs code supports both Linux ext2fs and BSD (chflags and stat). I assume xfsprogs and progreiserfs have similar functionality and routines. So what I am getting at ... instead of just ifdef'ing for HAVE_CHFLAGS, maybe it should have a common routines like fsetflags() and fgetflags() that can be adjusted for all. - 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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Jeremy C. Reed wrote:
> Why do the chflags(attr->olname, s.st_flags) "restore the fileflags of the
> sourcefile" twice?
once in case the 2nd linking failed (there is a return after that!)
and the 2nd time for the "linking was successfull" case.
> Also the first reset of the chflags() should probably have error checking
> and debugging there too (specific for that). (That's what I have added to
> my own code.)
The first chflags has error checking and reporting (rest file flags to
none)
Qmsg2(jcr, M_ERROR, 0, _("Could not reset file flags for file %s: ERR=%s\n"),
The second chflags has error checking and reporting as well (restore file
flags in case of 2nd linking failed too and return)
Qmsg2(jcr, M_ERROR, 0, _("Could not restore file flags for file %s:
ERR=%s\n"),
The third chflags has error checking and reporting as well (restore file
flags in case of linking was successfull)
Qmsg2(jcr, M_ERROR, 0, _("Could not restore file flags for file %s:
ERR=%s\n"),
> A hardlink is just a normal file -- it does have mode, ownership and
> access and modification times. (I think maybe you just typed wrong word
> above and didn't mean that.)
Better say a normal/regular file is just another hardlink ;)
All hardlinks/normal/regular files/whatever pointing to the same inode. This
is why all hardlinks share the same attributes. Attributes are along with other
file informations stored inside the inode. -> all hardlinks same attributes.
Thats why I said that setting attributes for, you might say the same inode,
more than once doesn't need to be. That was why I changed set_attributes()
to not set the attributes again when the filetype is FT_LNKSAVED because then
there is another file pointing to the same inode, already in the filesystem
or has been restored before (otherwise the link() call in create_file would
have failed). In the first case setting the attributes would be even wrong.
In the second case it would not harm to set the attributes once more if there
wouldn't be such file flags like schg which are preventing this.
>
> Also a symlink has a mode (which can be changed but probably on all BSDs
> it isn't even honored), ownership and modification time (time of symlink
> creation) and change time (time of last file status change). I can see all
> of this easily.
A Symlink can have its own attributs which can be set too (lchmod(), lchown(),
lutimes()), this is right because it has an own inode to store the information.
--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/
-
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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
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 attribut
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
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.
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
On Wednesday 13 December 2006 12:01, Oliver Lehmann wrote: > Hi Kern, > > it is ok when you want me to deliver the patch in a defined format. I've no > problems with that. I must say that I didn't read the developer manual > before I sent the patch, but I hope the patch does now comply to the rules. > I've changed the indention from my former patch so you can see that > everything which changed/was added was done inside the ifdef preprocessor > directives. Yes, nice. Thanks. That is a big help. :-) > This is a first step. The problems with the attribues can be "fixed" later. > With this patch at least the links are getting created which is better than > before. Many thanks. Your patch looks perfectly fine to me. I'll integrate it shortly. > > Greetings, Oliver > - 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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
> patch-src-findlib-create_file.c
> Try to unset file flags of the sourcefile when the hardlink failed.
> Retry to hardlink then. If the hardlink fails then again, restore the
> file flags of the sourcefile. If the hardlink was created w/o errors,
> restore the fileflags of the sourcefile.
Why do the chflags(attr->olname, s.st_flags) "restore the fileflags of the
sourcefile" twice?
Also the first reset of the chflags() should probably have error checking
and debugging there too (specific for that). (That's what I have added to
my own code.)
> 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 don't understand this but may look closer at your code.
A hardlink is just a normal file -- it does have mode, ownership and
access and modification times. (I think maybe you just typed wrong word
above and didn't mean that.)
Also a symlink has a mode (which can be changed but probably on all BSDs
it isn't even honored), ownership and modification time (time of symlink
creation) and change time (time of last file status change). I can see all
of this easily. (I am not sure if access time ever changes as I didn't
look at source and never saw that.)
-
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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Hello, On Wednesday 13 December 2006 10:11, Oliver Lehmann wrote: > Hi Kern, > > Kern Sibbald writes: > > > 1. They are not relative to the current CVS. > > Hm, they are applying to it, or? At least I tried that.. > > > 2. They are a significant change from the current code, which is not a problem > > during the development cycle, but *is* a major problem at this point. > > This I understand and I agree fully here. when 1.40 is at the end of the > release cycle this change is too sweeping to include. But maybe for a later > release it is ok. For so long it can be kept as local patches... > > > > 3. They seem to change non-FreeBSD code -- perhaps not the functionality but > > by adding a switch(). > > If that is a problem, it can also be done by using if() but I found switch() > more suitable here. > > > On the other hand, I would suggest that you work with Jeremy Reed as his patch > > once it is appropriately tweaked is something that I could see adding to 1.40 > > because: > > 1. It is relative to the CVS > > 2. It makes the mininum necessary changes > > 3. For the most part the changes seem to be FreeBSD specific > > patch-src-findlib-create_file.c is based on his patch. I just added the > restore of the file flags on failure, and error messages in case of > failures. What is the problem with it and the CVS version? I would like to put in a fix for the hardlink failure problem and possibly for the attiributes update errors problem, but I need as I said before: 1. A simple patch (or two if you want) that is the absolute minimal change and if at all possible modifies only FreeBSD code. 2. The diff must be done against the current CVS not against a file named xxx.orig which I have no idea where it came from or what version it is. Look at Jeremy Reed's diff, you will see that it is done against the cvs and thus packed with all kinds of additional information that I need. You may feel that I am being a bit picky here, which is probably the case, but this is documented in the Developer's manual and *really* helps to make communication of patch files and their integration *much* more smooth and sure. 3. A really minor point is that the patch should be an attachment (as you did), but it should be named xxx.patch e.g. chflag.patch or findlib-attribs.patch or create_file.patch. What you are sending me is not a .c file, so shouldn't be named that way. It makes reading it harder -- since then my email reader knows what the content is and calls the correct viewing program when I open it. 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 Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Hello,
I've now taken a look at these patches and though they might be going in the
right direction, I cannot consider them for inclusion in version 1.40 for
several reasons:
1. They are not relative to the current CVS.
2. They are a significant change from the current code, which is not a problem
during the development cycle, but *is* a major problem at this point.
3. They seem to change non-FreeBSD code -- perhaps not the functionality but
by adding a switch().
On the other hand, I would suggest that you work with Jeremy Reed as his patch
once it is appropriately tweaked is something that I could see adding to 1.40
because:
1. It is relative to the CVS
2. It makes the mininum necessary changes
3. For the most part the changes seem to be FreeBSD specific
His patch only addresses one of the two problems mentioned, so perhaps there
is more work to be done.
Regards,
Kern
On Wednesday 13 December 2006 07:54, Oliver Lehmann wrote:
> Kern Sibbald wrote:
>
> > Please fix it up correctly, then send it to me in the same diff format
versus
> > the current CVS, but please send it as an attachment to avoid the
possibility
> > of word wrap. I'll then take a look at putting it in the code. If you
send
> > it in the next few days, it will probably become part of 1.40.0 ...
>
> I've attached 2 patches (will both apply with some offset)
>
> patch-src-findlib-create_file.c
> Try to unset file flags of the sourcefile when the hardlink failed.
> Retry to hardlink then. If the hardlink fails then again, restore the
> file flags of the sourcefile. If the hardlink was created w/o errors,
> restore the fileflags of the sourcefile.
>
> 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
>
>
> --
> Oliver Lehmann
> http://www.pofo.de/
> http://wishlist.ans-netz.de/
>
-
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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
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
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Hello,
I haven't yet looked at the patches, but here are a couple of preliminary
comments. I'll take a careful look at the patches later today.
On Wednesday 13 December 2006 07:54, Oliver Lehmann wrote:
> Kern Sibbald wrote:
>
> > Please fix it up correctly, then send it to me in the same diff format
versus
> > the current CVS, but please send it as an attachment to avoid the
possibility
> > of word wrap. I'll then take a look at putting it in the code. If you
send
> > it in the next few days, it will probably become part of 1.40.0 ...
>
> I've attached 2 patches (will both apply with some offset)
>
> patch-src-findlib-create_file.c
> Try to unset file flags of the sourcefile when the hardlink failed.
> Retry to hardlink then. If the hardlink fails then again, restore the
> file flags of the sourcefile. If the hardlink was created w/o errors,
> restore the fileflags of the sourcefile.
OK, this sounds very good. Thanks.
>
> 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, ...).
-
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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Kern Sibbald wrote:
> Please fix it up correctly, then send it to me in the same diff format versus
> the current CVS, but please send it as an attachment to avoid the possibility
> of word wrap. I'll then take a look at putting it in the code. If you send
> it in the next few days, it will probably become part of 1.40.0 ...
I've attached 2 patches (will both apply with some offset)
patch-src-findlib-create_file.c
Try to unset file flags of the sourcefile when the hardlink failed.
Retry to hardlink then. If the hardlink fails then again, restore the
file flags of the sourcefile. If the hardlink was created w/o errors,
restore the fileflags of the sourcefile.
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
--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/
--- ./src/findlib/attribs.c.orig Wed Dec 13 07:18:20 2006
+++ ./src/findlib/attribs.c Wed Dec 13 07:26:49 2006
@@ -43,6 +43,7 @@
#define lchown chown
#endif
+
/*=*/
/* */
/* *** A l l S y s t e m s *** */
@@ -346,7 +347,8 @@
* For link, change owner of link using lchown, but don't
* try to do a chmod as that will update the file behind it.
*/
- if (attr->type == FT_LNK) {
+ switch (attr->type) {
+ case FT_LNK:
/* Change owner of link, not of real file */
if (lchown(attr->ofname, attr->statp.st_uid, attr->statp.st_gid) < 0) {
berrno be;
@@ -354,7 +356,25 @@
attr->ofname, be.strerror());
ok = false;
}
- } else {
+#ifdef HAVE_CHFLAGS
+ /*
+ * FreeBSD user flags
+ *
+ * Note, this should really be done before the utime() above,
+ * but if the immutable bit is set, it will make the utimes()
+ * fail.
+ */
+ if (lchflags(attr->ofname, attr->statp.st_flags) < 0) {
+ berrno be;
+ Jmsg2(jcr, M_ERROR, 0, _("Unable to set file flags %s: ERR=%s\n"),
+attr->ofname, be.strerror());
+ ok = false;
+ }
+#endif
+ break;
+ case FT_LNKSAVED:
+ break;
+ default:
if (chown(attr->ofname, attr->statp.st_uid, attr->statp.st_gid) < 0) {
berrno be;
Jmsg2(jcr, M_ERROR, 0, _("Unable to set file owner %s: ERR=%s\n"),
--- src/findlib/create_file.c.orig Tue May 2 16:48:16 2006
+++ src/findlib/create_file.c Tue Dec 12 23:58:55 2006
@@ -304,9 +304,46 @@
Dmsg2(130, "Hard link %s => %s\n", attr->ofname, attr->olname);
if (link(attr->olname, attr->ofname) != 0) {
berrno be;
-Qmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s: ERR=%s\n"),
- attr->ofname, attr->olname, be.strerror());
-return CF_ERROR;
+#ifdef HAVE_CHFLAGS
+struct stat s;
+
+/*
+* If using BSD user flags, maybe has a file flag
+* preventing this. So attempt to disable, retry link,
+* and reset flags.
+* Note that BSD securelevel may prevent disabling flag.
+ */
+
+if (stat(attr->olname, &s) == 0 && s.st_flags != 0) {
+ if (chflags(attr->olname, 0) == 0) {
+ if (link(attr->olname, attr->ofname) != 0) {
+ /* restore original file flags even when linking failed */
+ if (chflags(attr->olname, s.st_flags) < 0) {
+Qmsg2(jcr, M_ERROR, 0, _("Could not restore file flags for file %s: ERR=%s\n"),
+ attr->olname, be.strerror());
+ }
+#endif /* HAVE_CHFLAGS */
+ Qmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s: ERR=%s\n"),
+ attr->ofname, attr->olname, be.strerror());
+ return CF_ERROR;
+#ifdef HAVE_CHFLAGS
+ }
+ /* finally restore original file flags */
+ if (chflags(attr->olname, s.st_flags) < 0) {
+ Qmsg2(jcr, M_ERROR, 0, _("Could not restore file flags for file %s: ERR=%s\n"),
+attr->olname, be.strerror());
+ }
+ } else {
+ Qmsg2(jcr, M_ERROR, 0, _("Could not reset file flags for file %s: ERR=%s\n"),
+ attr->olname, be.strerror());
+ }
+} else {
+ Qmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s: ERR=%s\n"),
+attr->ofname, attr->olname, b
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
On Tuesday 12 December 2006 23:01, Jeremy C. Reed wrote: > > Here is an untested patch (or at least an idea :) that should help those > > who don't use raised securelevel. This patch needs some debug output for > > both chflags introduced here. > > > > Index: src/findlib/create_file.c > > I see my patch is missing a closing brace. And also it fails to return > error if no file flags. If someone will use this code, I will finish it > up. > Please fix it up correctly, then send it to me in the same diff format versus the current CVS, but please send it as an attachment to avoid the possibility of word wrap. I'll then take a look at putting it in the code. If you send it in the next few days, it will probably become part of 1.40.0 ... - 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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Oliver Lehmann wrote: > The patch I sent was not correct because ofname and olname where mixed up > when doing the flags work. I fixed this now, and I tried restoring > my /usr/bin. It now created the hardlinks, but gave me errors that the owner > and times of the hardlinks are not setable (because of the same thing) errormessages are: 3-Dec 00:03 nudel-fd: client-gurke-files-r.2006-12-13_00.00.30 Error: attribs.c:361 Unable to set file owner /mnt/files/.bacula/restores/test/usr/bin/yppasswd: ERR=Operation not permitted 13-Dec 00:03 nudel-fd: client-gurke-files-r.2006-12-13_00.00.30 Error: attribs.c:367 Unable to set file modes /mnt/files/.bacula/restores/test/usr/bin/yppasswd: ERR=Operation not permitted 13-Dec 00:03 nudel-fd: client-gurke-files-r.2006-12-13_00.00.30 Error: attribs.c:377 Unable to set file times /mnt/files/.bacula/restores/test/usr/bin/yppasswd: ERR=Operation not permitted 13-Dec 00:03 nudel-fd: client-gurke-files-r.2006-12-13_00.00.30 Error: attribs.c:361 Unable to set file owner /mnt/files/.bacula/restores/test/usr/bin/ypchsh: ERR=Operation not permitted 13-Dec 00:03 nudel-fd: client-gurke-files-r.2006-12-13_00.00.30 Error: attribs.c:367 Unable to set file modes /mnt/files/.bacula/restores/test/usr/bin/ypchsh: ERR=Operation not permitted 13-Dec 00:03 nudel-fd: client-gurke-files-r.2006-12-13_00.00.30 Error: attribs.c:377 Unable to set file times /mnt/files/.bacula/restores/test/usr/bin/ypchsh: ERR=Operation not permitted [...] -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ - 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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
The patch I sent was not correct because ofname and olname where mixed up
when doing the flags work. I fixed this now, and I tried restoring
my /usr/bin. It now created the hardlinks, but gave me errors that the owner
and times of the hardlinks are not setable (because of the same thing)
How relevant is setting those two things anyway? Is it possible that a hard-
link has other time stats or belongs other owner/groups as it's sourcefile?
If those two atributs has to be considered for hardlinks too, a similar patch
has to be applied to atrribs.c I'd say. W/o looking into it I'm not sure if
there is olname defined?
I'll continue testing tomorrow *yawn*
--- src/findlib/create_file.c.orig Tue May 2 16:48:16 2006
+++ src/findlib/create_file.c Tue Dec 12 23:58:55 2006
@@ -304,9 +304,46 @@
Dmsg2(130, "Hard link %s => %s\n", attr->ofname, attr->olname);
if (link(attr->olname, attr->ofname) != 0) {
berrno be;
-Jmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s: ERR=%s\n"),
- attr->ofname, attr->olname, be.strerror());
-return CF_ERROR;
+#ifdef HAVE_CHFLAGS
+struct stat s;
+
+/*
+* If using BSD user flags, maybe has a file flag
+* preventing this. So attempt to disable, retry link,
+* and reset flags.
+* Note that BSD securelevel may prevent disabling flag.
+ */
+
+if (stat(attr->olname, &s) == 0 && s.st_flags != 0) {
+ if (chflags(attr->olname, 0) == 0) {
+ if (link(attr->olname, attr->ofname) != 0) {
+ /* restore original file flags even when linking failed */
+ if (chflags(attr->olname, s.st_flags) < 0) {
+Jmsg2(jcr, M_ERROR, 0, _("Could not restore file flags
for file %s: ERR=%s\n"),
+ attr->olname, be.strerror());
+ }
+#endif /* HAVE_CHFLAGS */
+ Jmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s:
ERR=%s\n"),
+ attr->ofname, attr->olname, be.strerror());
+ return CF_ERROR;
+#ifdef HAVE_CHFLAGS
+ }
+ /* finally restore original file flags */
+ if (chflags(attr->olname, s.st_flags) < 0) {
+ Jmsg2(jcr, M_ERROR, 0, _("Could not restore file flags
for file %s: ERR=%s\n"),
+attr->olname, be.strerror());
+ }
+ } else {
+ Jmsg2(jcr, M_ERROR, 0, _("Could not reset file flags for file
%s: ERR=%s\n"),
+ attr->olname, be.strerror());
+ }
+} else {
+ Jmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s:
ERR=%s\n"),
+attr->ofname, attr->olname, be.strerror());
+ return CF_ERROR;
+}
+#endif /* HAVE_CHFLAGS */
+
}
return CF_CREATED;
#endif
--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/
-
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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
Jeremy C. Reed wrote:
> > Here is an untested patch (or at least an idea :) that should help those
> > who don't use raised securelevel. This patch needs some debug output for
> > both chflags introduced here.
> >
> > Index: src/findlib/create_file.c
>
> I see my patch is missing a closing brace. And also it fails to return
> error if no file flags. If someone will use this code, I will finish it
> up.
I'm trying right now with the following patch. It is a bit of redundant code
(error handling, flag restoring), but I think it should work...
--- src/findlib/create_file.c.orig Tue May 2 16:48:16 2006
+++ src/findlib/create_file.c Tue Dec 12 22:50:22 2006
@@ -304,9 +304,42 @@
Dmsg2(130, "Hard link %s => %s\n", attr->ofname, attr->olname);
if (link(attr->olname, attr->ofname) != 0) {
berrno be;
-Jmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s: ERR=%s\n"),
- attr->ofname, attr->olname, be.strerror());
-return CF_ERROR;
+#ifdef HAVE_CHFLAGS
+struct stat s;
+
+/*
+* If using BSD user flags, maybe has a file flag
+* preventing this. So attempt to disable, retry link,
+* and reset flags.
+* Note that BSD securelevel may prevent disabling flag.
+ */
+
+if (stat(attr->ofname, &s) == 0 && s.st_flags != 0 &&
+ chflags(attr->ofname, 0) == 0) {
+ if (link(attr->olname, attr->ofname) != 0) {
+ /* restore original file flags even when linking failed */
+ if (chflags(attr->ofname, s.st_flags) < 0) {
+ Jmsg2(jcr, M_ERROR, 0, _("Could not restore file flags
for file %s: ERR=%s\n"),
+ attr->olname, be.strerror());
+ }
+#endif /* HAVE_CHFLAGS */
+ Jmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s:
ERR=%s\n"),
+attr->ofname, attr->olname, be.strerror());
+ return CF_ERROR;
+#ifdef HAVE_CHFLAGS
+ }
+ /* finally restore original file flags */
+ if (chflags(attr->ofname, s.st_flags) < 0) {
+ Jmsg2(jcr, M_ERROR, 0, _("Could not restore file flags for
file %s: ERR=%s\n"),
+ attr->olname, be.strerror());
+ }
+} else {
+ Jmsg3(jcr, M_ERROR, 0, _("Could not hard link %s -> %s:
ERR=%s\n"),
+attr->ofname, attr->olname, be.strerror());
+ return CF_ERROR;
+}
+#endif /* HAVE_CHFLAGS */
+
}
return CF_CREATED;
#endif
--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/
-
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
Re: [Bacula-users] [Bacula-devel] problems with hardlinks to "schg" secured files on FreeBSD on restore
> Here is an untested patch (or at least an idea :) that should help those > who don't use raised securelevel. This patch needs some debug output for > both chflags introduced here. > > Index: src/findlib/create_file.c I see my patch is missing a closing brace. And also it fails to return error if no file flags. If someone will use this code, I will finish it up. - 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
