RE: [PHP] umask() and chmod()
On 15 April 2004 16:26, David T-G wrote: Hi, all -- When I move_uploaded_file() a file into place, I want to give it the correct permissions; by default they are 600 (rw-/---/--). I already have the umask set correctly for any given situation in anticipation of creating directories, and that works for creating files from scratch, but chmod() needs a permissions setting rather than a umask. The challenge is in representing this as octal. With some mucking around I was able to print $u = decoct(umask()) ; $m = 0777 ; $r = decoct($m) - $u ; print The setting is $r\n ; and get The setting is 664 when umask returns 113. All is great, right? Well, no... I need to convert that 664 octal value into an octal representation of 0664 to feed to chmod() -- and apparently I can't just $r = 0.$r ; That would be $r = '0'.$r; I'm not sure, however, that this is a totally foolproof way of doing it, as it would fail with any permission set (however unlikely) where the owner odgit was a zero -- perhaps you should be sprintf()-ing it? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] umask() and chmod()
Mike, et al -- ...and then Ford, Mike [LSS] said... % % On 15 April 2004 16:26, David T-G wrote: % % but chmod() needs a permissions setting rather than a umask. % % The challenge is in representing this as octal. With some ... % to feed to chmod() -- and apparently I can't just % %$r = 0.$r ; % % That would be % % $r = '0'.$r; Hmmm... OK. % % I'm not sure, however, that this is a totally foolproof way of doing it, as % it would fail with any permission set (however unlikely) where the owner Would it? Suppose I were setting it to 007; that would be 0007 with the leading zero and should still be fine. % odgit was a zero -- perhaps you should be sprintf()-ing it? Heck, I'll take any advice I can get :-) I think, though, that the problem is that I'm trying to use a string -- if I can get it built correctly in the first place -- as an octal digit. % % Cheers! % % Mike Thanks HAND :-D -- David T-G [EMAIL PROTECTED] http://justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg! pgp0.pgp Description: PGP signature
RE: [PHP] umask() and chmod()
On 15 April 2004 17:26, David T-G wrote:
Mike, et al --
...and then Ford, Mike [LSS] said...
%
% On 15 April 2004 16:26, David T-G wrote:
%
% but chmod() needs a permissions setting rather than a umask. %
% The challenge is in representing this as octal. With some ...
% to feed to chmod() -- and apparently I can't just %
%$r = 0.$r ;
%
% That would be
%
% $r = '0'.$r;
Hmmm... OK.
%
% I'm not sure, however, that this is a totally foolproof way
of doing it, as
% it would fail with any permission set (however unlikely)
where the owner
Would it? Suppose I were setting it to 007; that would be 0007 with
the leading zero and should still be fine.
No. The way you're building it, $r would be an integer before you add the leading
zero -- 007 would thus be represented as just 7, and adding the leading zero the way
I've shown above would give '07'. Not good.
% odgit was a zero -- perhaps you should be sprintf()-ing it?
Heck, I'll take any advice I can get :-) I think, though, that the
problem is that I'm trying to use a string -- if I can get it built
correctly in the first place -- as an octal digit.
Possibly, but I think you're making the whole thing more complicated than it need be.
After a quick look at the manual, I'd suggest this:
$u = umask(); // Integer value of umask -- no need to convert
// to octal representation as that's just a human
// convenience of no value to your computer ;)
$m = 0777; // $m is now an integer corresponding to octal
// 0777 again, the visual representation of this
// in octal (or binary, or hex...) is just a
// human convenience.
$r = $m ^ $u; // remove bits set in $u from $m (subtract should
// work too, but since this is technically a
// bitwise operation, I prefer the bitwise
// operator!
// $r is now the correct value, and just needs representing in octal:
$r = sprintf('%04o', $r);
// Done -- use it as you wish.
Of course, I've been quite verbose there -- the short version is:
$r = sprintf('%04o', 0777 ^ umask());
... ;))
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] umask() and chmod()
On 15 April 2004 16:26, David T-G wrote: Hi, all -- When I move_uploaded_file() a file into place, I want to give it the correct permissions; by default they are 600 (rw-/---/--). I already have the umask set correctly for any given situation in anticipation of creating directories, and that works for creating files from scratch, but chmod() needs a permissions setting rather than a umask. The challenge is in representing this as octal. With some mucking around I was able to print $u = decoct(umask()) ; $m = 0777 ; $r = decoct($m) - $u ; print The setting is $r\n ; I've just re-read this properly, and realised you want to feed the end value to chmod() -- so all the guff about octal representations is a complete red herring. What you want to feed to the 2nd parameter of chmod() is just: 0777 ^ umask() Within the computer, the value is just an integer, and that's what umask() provides and what chmod() expects for its 2nd argument -- so no conversions required. Even 0777 is an integer -- it's just a different way of representing 511 which is more understandable to us poor humans in that context. Your original offering was, in fact, barking up the wrong tree -- what it was printing out, although it looked right, was the *decimal* value 664, which in octal would be 01230 and really not what you want. I guess what this boils down to is that integers are just integers when you manipulate them in your script -- octal, decimal, hex and any other representations are just convenient notations for making them more human readable. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] umask() and chmod()
Mike, et al -- Responding to your second one first... ...and then Ford, Mike [LSS] said... % % On 15 April 2004 16:26, David T-G wrote: % % When I move_uploaded_file() a file into place, I want to give it the ... % but chmod() needs a permissions setting rather than a umask. % % The challenge is in representing this as octal. With some ... % % I've just re-read this properly, and realised you want to feed the end value to chmod() -- so all the guff about octal representations is a complete red herring. What you want to feed to the 2nd parameter of chmod() is just: % % 0777 ^ umask() Ah! Cool! A bitwise NOT operator! Perfect :-) % % Within the computer, the value is just an integer, and that's what umask() provides and what chmod() expects for its 2nd argument -- so no conversions required. Even 0777 is an integer -- it's just a different way of representing 511 which is more understandable to us poor humans in that context. Right. % % Your original offering was, in fact, barking up the wrong tree -- what it was printing out, although it looked right, was the *decimal* value 664, which in octal would be 01230 and really not what you want. Right; I wanted to get it as a string and then turn the string into octal. % % I guess what this boils down to is that integers are just integers when you manipulate them in your script -- octal, decimal, hex and any other representations are just convenient notations for making them more human readable. Yep :-) % % Cheers! % % Mike Thanks again HAND :-D -- David T-G [EMAIL PROTECTED] http://justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg! pgp0.pgp Description: PGP signature
Re: [PHP] umask() and chmod()
Mike --
...and then Ford, Mike [LSS] said...
%
% On 15 April 2004 17:26, David T-G wrote:
%
% ...and then Ford, Mike [LSS] said...
% %
% % I'm not sure, however, that this is a totally foolproof way
% of doing it, as
% % it would fail with any permission set (however unlikely)
% where the owner
%
% Would it? Suppose I were setting it to 007; that would be 0007 with
% the leading zero and should still be fine.
%
% No. The way you're building it, $r would be an integer before you add the leading
zero -- 007 would thus be represented as just 7, and adding the leading zero the way
I've shown above would give '07'. Not good.
Indeed. But of course I was trying to work with a string...
%
...
% Heck, I'll take any advice I can get :-) I think, though, that the
% problem is that I'm trying to use a string -- if I can get it built
% correctly in the first place -- as an octal digit.
%
% Possibly, but I think you're making the whole thing more complicated than it need
be. After a quick look at the manual, I'd suggest this:
As I clearly was. But where did you see ^ in the manual?
Oh, I see it. I had to look for it as ^ but I found it. Oops; and it's
an XOR rather than a NOT.
%
...
% Of course, I've been quite verbose there -- the short version is:
%
% $r = sprintf('%04o', 0777 ^ umask());
And the final version, I'm happy to say, is
chmod ($target,0777^umask()) ;
and it works perfectly :-)
%
% ... ;))
%
% Cheers!
%
% Mike
Thanks again HAND
:-D
--
David T-G
[EMAIL PROTECTED]
http://justpickone.org/davidtg/ Shpx gur Pbzzhavpngvbaf Qrprapl Npg!
pgp0.pgp
Description: PGP signature
