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
