Chmod: Decimal vs. Octal

Hi,

I guess I need some clarification from Miva Inc. on this one.
To quote the manual's definition of the fchmod/schmod functions:

"fchmod() works like UNIX chmod and changes permissions to
mode_number on the file named by source_path in the data directory.
schmod() does the same in the script directory. The mode number must
be in the format nnnn (decimal) or 0nnnn (octal)."

As far as I have found Unix has two forms of chmod:

An absolute form which uses octal numbers (ie: 755) to represent the
permissions given to the three user types; owner, group and other.


A symbolic type which uses character groups (ie: -rwx-rx-rx) to
represent the permissions given to the three user types. Some
references also mention a forth user type, "all of the above" when
defining the symbolic form of chmod.

I can find no references to a "decimal form" of chmod in Unix.
A modest amount of testing reveals no easily discernible difference
between Miva's decimal and octal permission mode numbers
except for the number of leading zeros. Which brings me to my two
questions:

What exactly is the difference between Miva's decimal and octal
permission mode numbers and where is it appropriate to use each form?

Why does Miva have leading zeros in the permission mode numbers. Is
it something to do with Unix's "sticky bits? Can we do anything
useful with them?

I guess that last one is really more than one, sorry :)

Thank you,

Brian R. Bullock
[email protected]
Function Junction
<A HREF ="http://wwwebweaver.com/func_junc/">http://wwwebweaver.com/func_junc/</A>
The Miva Xbase3 Vending Machine
<A HREF ="http://wwwebweaver.com/db_vending/">http://wwwebweaver.com/db_vending/</A>

Chmod: Decimal vs. Octal



Ok, so assuming Miva is written in C then maybe I could understand a
single leading zero so miva doesn't need to parse the number before
using it (although I think it would be easy enough to let us use the
standard three digit number and have miva add its own zero).

But why two leading zeros in the octal form and why separate decimal
and octal forms if they parse to the same thing?

Brian


Gary Thompson wrote:

> Well, since the digital representation of the groups is based upon
> bits...
>
> UGO = U (111 = 7 = RWX) G (011 = 3 = WX) O (100 = 4 = R)
>
> It will only have a maximum value of 777, which can be handled in
> decimal... it may just discard the upper bits.
>
> In C, leading zeros represent octal format in hard-coded values...
> don't know how miva's works. Never found a use for chmod in miva
> yet.
>
> ==================================
> Gary Thompson
> "The Psycho"
> http://psycho.simplenet.com
> ==================================
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Brian R. Bullock
> > Sent: Thursday, September 02, 1999 5:35 PM
> > To: [email protected]
> > Subject: [meu] Chmod: Decimal vs. Octal
> >
> >
> > Hi,
> >
> > I guess I need some clarification from Miva Inc. on this one.
> > To quote the manual's definition of the fchmod/schmod functions:
> >
> > "fchmod() works like UNIX chmod and changes permissions to
> > mode_number on the file named by source_path in the data directory.
> > schmod() does the same in the script directory. The mode number must
> > be in the format nnnn (decimal) or 0nnnn (octal)."
> >
> > As far as I have found Unix has two forms of chmod:
> >
> > An absolute form which uses octal numbers (ie: 755) to represent the
> > permissions given to the three user types; owner, group and other.
> >
> >
> > A symbolic type which uses character groups (ie: -rwx-rx-rx) to
> > represent the permissions given to the three user types. Some
> > references also mention a forth user type, "all of the above" when
> > defining the symbolic form of chmod.
> >
> > I can find no references to a "decimal form" of chmod in Unix.
> > A modest amount of testing reveals no easily discernible difference
> > between Miva's decimal and octal permission mode numbers
> > except for the number of leading zeros. Which brings me to my two
> > questions:
> >
> > What exactly is the difference between Miva's decimal and octal
> > permission mode numbers and where is it appropriate to use each form?
> >
> > Why does Miva have leading zeros in the permission mode numbers. Is
> > it something to do with Unix's "sticky bits? Can we do anything
> > useful with them?
> >
> > I guess that last one is really more than one, sorry :)
> >
> > Thank you,
> >
> > Brian R. Bullock
> > [email protected]
> > Function Junction
> > <A HREF ="http://wwwebweaver.com/func_junc/">http://wwwebweaver.com/func_junc/</A>
> > The Miva Xbase3 Vending Machine
> > <A HREF ="http://wwwebweaver.com/db_vending/">http://wwwebweaver.com/db_vending/</A>
> >
> >

Chmod: Decimal vs. Octal



Hi Jack,

Your private letter earlier piqued my interest in this subject. I
couldn't answer any of your questions and I couldn't find any
difference in the way Miva handled decimal and octal permission
numbers. The latter outraged my sense of "fitness for purpose" so I
decided to take it public. I guess we'll see if there is any reaction
from Miva :)

Brian

R. Jackson Wilson wrote:

> Brian:
>
> Your research is thorough and exact.
>
> The difference between octal and decimal in the chmod functions is a
> figment of the imagination of whoever wrote the Reference. The
> number in question is not a "number" at all, but a sequence of
> digits.
>
> The only questions are: why four places? Why five for the "octal"
> option?
>
> Possible answers: On traditional Unix systems, it is possible to set
> the low-order byte of the high nibble to 1. This is the sticky bit
> that causes a copy of the program to be written to memory. (Don't
> know if Miva scripts qualify as "programs" for this purpose.)
>
> All Miva allows us to do is to set "absolute" permissions. In Unix,
> this allows the high nibble to be set to 1, 2, or 4:
> 1 = sticky bit set
> 2 = "Group ID is on is the file is executable; otherwise,
> mandatory file locking is on."
> 4 = "User ID bit on if the file is executable."
>
> My guess (and it is a guess) is that a script could (maybe) set a
> permissions level of (say) 03755, which would mean:
>
> group ID bit on if file is executable; otherwise mandatory
> file locking (whatever this means)
> sticky bit on
> user = all
> group = read and execute
> world = read and execute
>
> I emphasize that this is guesswork. I just don't know if Unix
> regards Miva programs as "executable," and if the high nibble of the
> chmod number has any effect using f/schmod().
>
> I look forward to any further research results you may obtain. Maybe
> some Unix mavens can clear this up. Drew?
>
> Jack
>
> -
> MAILTO:[email protected]
> Sample functions and scripts, NoteTab clipbooks, are available at:
> http://rjwilson.org/public/ along with a framed version of the hts
> 2.x Reference, for anyone who still uses that version.

Chmod: Decimal vs. Octal



Brian:

Your research is thorough and exact.

The difference between octal and decimal in the chmod functions is a
figment of the imagination of whoever wrote the Reference. The number in
question is not a "number" at all, but a sequence of digits.

The only questions are: why four places? Why five for the "octal"
option?

Possible answers: On traditional Unix systems, it is possible to set the
low-order byte of the high nibble to 1. This is the sticky bit that
causes a copy of the program to be written to memory. (Don't know if
Miva scripts qualify as "programs" for this purpose.)

All Miva allows us to do is to set "absolute" permissions. In Unix, this
allows the high nibble to be set to 1, 2, or 4:
1 = sticky bit set
2 = "Group ID is on is the file is executable; otherwise,
mandatory file locking is on."
4 = "User ID bit on if the file is executable."

My guess (and it is a guess) is that a script could (maybe) set a
permissions level of (say) 03755, which would mean:

group ID bit on if file is executable; otherwise mandatory
file locking (whatever this means)
sticky bit on
user = all
group = read and execute
world = read and execute

I emphasize that this is guesswork. I just don't know if Unix regards
Miva programs as "executable," and if the high nibble of the chmod
number has any effect using f/schmod().

I look forward to any further research results you may obtain. Maybe
some Unix mavens can clear this up. Drew?

Jack

-
MAILTO:[email protected]
Sample functions and scripts, NoteTab clipbooks, are available at:
http://rjwilson.org/public/ along with a framed version of the hts 2.x
Reference, for anyone who still uses that version.

Chmod: Decimal vs. Octal



Hi Joe,

Thanks for the quick answer!

Joseph Jay Austin wrote:

> <snip>
> Thus we would want the eighth and ninth bits on also:
> fchmod('file', 0660) or fchmod('file', 432)
>

Ok, I understand. To set all permissions for all user types is
fchmod('file', 0777) octal, or fchmod('file', 511) decimal.

The small acorn that grew into my mighty oak tree of confusion was,
what must be, a small typo in the manual.

The manual's definition of the fchmod/schmod functions contains the
sentence "The mode number must be in the format nnnn (decimal) or
0nnnn (octal)."

Since I already knew the value could not exceed 777 (octal) which is
three digits and the manual indicated that it was possible to have a
4 digit octal number then I "assumed" I needed another leading zero
as a placeholder. So then when I saw 4 digits in the decimal format
description (max of 511 = 3 digits) I was already conditioned to use
a zero as a placeholder. Of course this meant I was really using
octal when I thought I was using decimal because Miva understood
the leading zero to mean octal and I thought it was just a place
holder in a decimal number.

In retrospect my confusion was silly but sometimes a small
misunderstanding distorts the next thought and so on, and so on,
until nothing makes sense :)

Thanks again for cutting my gordian knot of confusion,

Brian R. Bullock
[email protected]
Function Junction
<A HREF ="http://wwwebweaver.com/func_junc/">http://wwwebweaver.com/func_junc/</A>
The Miva Xbase3 Vending Machine
<A HREF ="http://wwwebweaver.com/db_vending/">http://wwwebweaver.com/db_vending/</A>

Chmod: Decimal vs. Octal




Greetings Brian.

The mode number is actually a bit field
which is represented using a number. A
bit field is a series of bits whereby
each bit represents something that is
either on or off.

To better understand the different
numbering systems, consider the
following table:

Decimal Octal Binary
0 00 0
1 01 1
2 02 10
3 03 11
4 04 100
5 05 101
6 06 110
7 07 111
8 010 1000
9 011 1001
10 012 1010

All of the numbers above in each
row are the same number. They are
simply represented using a different
numbering system (i.e. decimal,
octal and binary).

The leading zero in the octal representation
is how Miva differentiates between octal
and decimal representations of a number.

For example: If the third bit (reading
from right to left) is on in the
Unix permissions bit field then it
means that the file may be read by
anyone. The binary representation
of the third bit on is 100, the octal
representation is 4 and the decimal
representation is 4. If the sixth
bit is on (again from right to left)
then the file may be read by members
of the group. The binary representation
is 100000, the octal representation is
40, and the decimal representation is 32.

The fifth bit on lets members of the
group write to the file. This is 20
in octal and 16 in decimal. If both
the fifth bit and the sixth bit are
on then the file may be read from
and written to by members of the group.
The binary representation of the fifth
and sixth bit on is 110000, the decimal
representation is 48 and the octal
representation is 60. Combining these
two bits together is called bitwise
or'ing in computer science terms.

Accordingly, to set a file so that
it is readable and writeable by members
of a group then we would use:

bit field binary oct dec
fifth bit on 10000 020 16
sixth bin on 100000 040 32
sixth and fifth 110000 060 48

fchmod('file', 060) or fchmod('file', 48)

The above example would have the interesting
effect of making the file writeable by all
members of the group except the owner! We
would probably want to allow the file owner
read and write permissions too. Thus we
would want the eighth and ninth bits on also:
fchmod('file', 0660) or fchmod('file', 432)

The meaning of the bits in the Unix
permissions bit field is most sensible
when used with octal numbers. For this
reason, I personally believe that it is
best to use octal representation when
using the fchmod() and schmod() functions.

- Joe


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Brian R. Bullock
> Sent: Thursday, September 02, 1999 2:35 PM
> To: [email protected]
> Subject: [meu] Chmod: Decimal vs. Octal
>
>
> Hi,
>
> I guess I need some clarification from Miva Inc. on this one.
> To quote the manual's definition of the fchmod/schmod functions:
>
> "fchmod() works like UNIX chmod and changes permissions to
> mode_number on the file named by source_path in the data directory.
> schmod() does the same in the script directory. The mode number must
> be in the format nnnn (decimal) or 0nnnn (octal)."
>
> As far as I have found Unix has two forms of chmod:
>
> An absolute form which uses octal numbers (ie: 755) to represent the
> permissions given to the three user types; owner, group and other.
>
>
> A symbolic type which uses character groups (ie: -rwx-rx-rx) to
> represent the permissions given to the three user types. Some
> references also mention a forth user type, "all of the above" when
> defining the symbolic form of chmod.
>
> I can find no references to a "decimal form" of chmod in Unix.
> A modest amount of testing reveals no easily discernible difference
> between Miva's decimal and octal permission mode numbers
> except for the number of leading zeros. Which brings me to my two
> questions:
>
> What exactly is the difference between Miva's decimal and octal
> permission mode numbers and where is it appropriate to use each form?
>
> Why does Miva have leading zeros in the permission mode numbers. Is
> it something to do with Unix's "sticky bits? Can we do anything
> useful with them?
>
> I guess that last one is really more than one, sorry :)
>
> Thank you,
>
> Brian R. Bullock
> [email protected]
> Function Junction
> <A HREF ="http://wwwebweaver.com/func_junc/">http://wwwebweaver.com/func_junc/</A>
> The Miva Xbase3 Vending Machine
> <A HREF ="http://wwwebweaver.com/db_vending/">http://wwwebweaver.com/db_vending/</A>
>
>

Chmod: Decimal vs. Octal



Joe:

You wrote:

---------------------------------------
Accordingly, to set a file so that
it is readable and writeable by members
of a group then we would use:

bit field binary oct dec
fifth bit on 10000 020 16
sixth bin on 100000 040 32
sixth and fifth 110000 060 48

fchmod('file', 060) or fchmod('file', 48)

----------------------------------------------------------------------
This is perfectly clear. The confusion grew in part out of the manual's
declaration that the number must be in the format "nnnn (decimal) or
0nnnn (octal)." This made it seem that we would have to write -- using
your example, fchmod('file', 00060) to pass an octal number, and
fchmod('file',0048) to pass a decimal number. In other words, the manual
makes it seem that you need to place a leading zero in a number that you
intend to be decimal, in order to fill out the four-digit nnnn
requirement. What your explanation makes clear is that any number
without a leading 0 is interpreted as a decimal, and any number with a
leading decimal is interpreted as an octal. Good.

So fchmod('file', 048) would produce an error? (since 8 doesn't exist in
octal). And fchmod('file', 060) would not?

You do not take up the question of the fourth octal nibble. Leaving
aside what servers will allow, will Miva allow the setting of bits in
the fourth nibble. That is, would Miva allow fchmod('file', 01755) or
fchmod('file', 03755)? I'm not asking what servers would allow; that's
none of Miva's business. I just would like to know what Miva will
process.

Jack

PS: I think it's just great when the CEO tunes in.

--
MAILTO:[email protected]
Sample functions and scripts, NoteTab clipbooks, are available at:
http://rjwilson.org/public/ along with a framed version of the hts 2.x
Reference, for anyone who still uses that version.

Chmod: Decimal vs. Octal



Joseph....

>Greetings Brian.
>
>The mode number is actually a bit field
>which is represented using a number. A
>bit field is a series of bits whereby
>each bit represents something that is
>either on or off.


Don't you think that you were talking *down* to Brian just a little bit?
After all, he's the same person that was on the ball enough to write the DB
Vending Machine, DB Expander and I don't know what all.

later.....duke

Chmod: Decimal vs. Octal



Lets not be so sensitive... If the question seemed basic to that person
responding, then the answer is probably very basic. Yes, it may have talked
"down" to Brian, but I'm sure it was informative to someone on the list...

Lets not worry too much about talking up or down at people... this list is for
information and I'd rather see too much than too little because everyone is
worrying about talking down to someone or hurting their feelings.

Let's just keep a open flow of info going on here and don't take any
answers/remarks personally.

Greg

PS. Sorry if I hurt your feelings. :)


Duke Normandin wrote:

> Joseph....
>
> >Greetings Brian.
> >
> >The mode number is actually a bit field
> >which is represented using a number. A
> >bit field is a series of bits whereby
> >each bit represents something that is
> >either on or off.
>
> Don't you think that you were talking *down* to Brian just a little bit?
> After all, he's the same person that was on the ball enough to write the DB
> Vending Machine, DB Expander and I don't know what all.
>
> later.....duke
>