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.
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.
Let me put it this way: I'm not opposed to adding a special flag for
hardlinks if it turns out its actually needed, but I'm not really
convinced we need it.
- Panu -
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
