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
