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 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
