[Rpm-maint] FSM hooks for rpm plugin
pmatilai at laiskiainen.org
Wed Mar 6 17:27:24 UTC 2013
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 -
More information about the Rpm-maint