-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Markus,
Thanks for looking things over, but I have a few questions.
On 12/13/2009 01:09 AM, Markus Roberts wrote:
> That's an interesting patch, nicely done so far as it goes, but (by my
> reading at least) it needs to be rethought a little to work as
> expected. There are basically two problems*:
>
> 1) Some of the allowed modes, such as g+w are actually mode _changes_,
> that only specify some of the bits. There's nothing I can see to stop
> people from only partially specifying the mode.
This was actually part of the intent. The mode starts at 0000, but then
gets re-mapped if the file exists. This seems to work the way I expect
in preliminary testing.
The scenario that I needed was one where I honestly didn't care what
other group bits were set, but I needed to be sure that write was gone.
So, I just wanted to be able to specify g-w and leave r and x alone. I
also didn't know what the actual mode would be set to.
This started to come up far too often and, after experimenting with the
normal symbolic chmod, the patch implements the expected behavior as
closely as possible.
>
> 2) The value that escapes from munge isn't canonical; the same bit
> pattern could be represented in multiple ways.
I think I understand what you're saying here, but I don't quite follow.
Munge is now returning either a bit pattern or a symbolic mode string.
I checked the parts of the code that seemed to be checking for mode
synchronization and I couldn't find a difference.
>
> The second is, I suspect, the cause of the constant resetting, as the
> but the first is going to be just a much of a problem.
Could you perhaps provide the data flow that I'm missing? I checked
what I thought was the output from the in_sync? function and, while it
returned 'false', I couldn't figure out why.
>
> A couple of alternatives I can see:
>
> * Break all the bits out as separate parameters ("owner_write",
> "owner_read", etc.) and rework mode as a shorthand for setting them.
> This would arguably be the most powerful (since it gives meaning to
> things like o+x) but it would also be massive overkill for the common
> case.
>
> * Move the symbolic interpretation into munge and have it only accept
> /^([ugoa]+)=([rwx]+)$/ or (perhaps a delimited list of them), and
> return the value as if they's specified a number
I see what you're saying, but I'm not sure why it makes a difference.
Perhaps, I'm not following the full impact of munge. I'll give it a try
and see if it clears things up.
And, it turns out that the regex that I wanted was:
/^(([ugoa]+)([+-=])([rwx]+),?)+$/
You can specify pretty much anything separated by commas, even things
that make no sense and the chmod command just applies them from left to
right. Kind of funky, but this is legal:
chmod ugo=rwx,g-x,u=r,g-w foo
results in => -r--r--rwx foo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksk+SsACgkQyjMdFR1108BeRQCeJVQiNLG8WvTVSdoN7L+eGvlJ
lM8AnA0Vqth/J8ctN5Hg5Yv4wcpK1TM9
=QVMk
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
