On 03/06/2013 05:01 PM, Reshetova, Elena wrote: >> What's missing is that another call to the hook is needed in >> fsmMkdirs() for the unowned directories, and there we should perhaps pass >> in the "unowned" >> aspect somehow. Having a separate argument for that seems like an >> overkill though... maybe we could pass that piece of info in the >> action argument instead. One possibility could be adding a new >> action, eg FA_CREATEUNOWNED that could be used for unowned >> directories (and files, but there aren't any currently). Or we could >> define the action as a partial bitfield: leave the existing actions >> alone but reserve the "upper" byte for special bits, such as >> "unknown". I had some other use-case for turning it into (partial) bitfield >> but can't remember what it was right now. > > I think bitfield would be better in this case: if one start introduce > actions FA_CREATEUNOWNED, then why not have FA_CREATELINK and etc. I > will add hook calling for mkdirs, but I think it is better that you do > a change of actions in a separate commit.
>Sure, and I agree bitfield seems like the better option as it'll allow >cramming a whole lot more information in there. There's a whole lot of >redundancy in the current actions (all the skip cases for example) and some >of the values are totally unused as well. >As the file actions aren't really exported in the API in a way that somebody >could actually be using them, we might be able to get away with just >redefining the whole thing as a bitfield and add the old symbols as defines >or'ed together from the bits. But I'll need to think about it some more, in >any case such >a total conversion is not required in order to add a handful >of bits right now. Ok, I think if you can add an "unowned" bit to it for a start, this can be a good beginning and then even the existing pre/post hooks can get one less argument, which is great. > Continue on bit field idea, it would be great for plugins to get the > basic info about the file acted upon from action also: so , if we are > adding unowned bit, should the basic bits indicating hard or sym link > be also supplied in action? Like action could point that it is > creation of symlink or removal of hard link. Is it too bad idea? >Hmm, but we already pass the mode (and planning to pass the whole stat >struct) around, so you can tell whether its a symlink, directory or something >else. Hardlinks are the more special case but you can tell them apart from >others by st_nlinks from the stat struct. Except that you dont necessarily >know which one is "real" file without extra tracking... unless st_nlinks is 1 >for real >files (including the first >hardlink) and more for the actual links. I'm not sure if that's the case even >already, but should be possible to arrange at least. I am quite sure you can't tell it from stat struct which is real file and which is hard link: the value for st_nlinks is stored in inode and not in dentry in my understanding, that's why it isn't really easy for plugin to detect the hard links, so indicator would be a plus... Best Regards, Elena.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint