> Thanks Dave... I'm not even sure what a "umask" is. heh :) It'd been a
> while since I'd done anything with it, and you know, googling for
> chmod doesn't produce very intuitive results. :)
>
No worries. I've always found umask to be counter-intuitive. Briefly,
what it does is sets the default *disabled* bit permissions for a new
directory (using mkdir). It is a configurable setting that is usually
found in your profile script (if you use the bash shell, it would
likely be in your .bash_profile). What I mean by disabled bits is that
its value determines what permissions the directory *doesn't* have, as
opposed to the permissions the directory *does* have. Since we tend to
think in terms of permissions that a directory does have (i.e., chmod
755 directory_name), umask just seems like a funny implementation
(much like using compare() and NOT compare() in CF!!).
The most common umask I've seen is 022. So to determine what
permissions a directory will have by default, you'd subtract the umask
value from 777 (which is the bit representation for full
read/write/execute permissions):
777
- 022
---------
755
So 755 will be the default permissions on creating all directories
under your user name, which is full read/write/execute for the owner,
and read/execute for the group and others.
I know this is way more information than you probably ever wanted, but
hopefully this helps you understand better why umask wasn't the answer
to the initial post's problem.
Regards,
Dave.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
