10.2.2 is out - Page 3

mervTormel · 11-12-2002, 04:42 PM

well, you'd think, in this case, it means "special ed" perms, but in examining the bom entry, it becomes clear...

$ lsbom -p fm /Library/Receipts/MacOSXUpdate10.2.2.pkg/Contents/Archive.bom | grep hfs.fs/hfs.util

./System/Library/Filesystems/hfs.fs/hfs.util 100755

100755 octal == 33261 decimal

thatch · 11-12-2002, 05:07 PM

mT,

Excellent! But I had thought that 4755 was the octal number. So, I am not computing correctly somehow. However, I had thought about converting octal to decimal and visa versa before. Maybe I should go back to special ed to find the equation.

...

I had a look at this which is from my 10.2.1 install:

Code:

lsbom -p fm /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom | grep hfs.fs/hfs.util
./System/Library/Filesystems/hfs.fs/hfs.util    104755

Very interesting, eh?

mervTormel · 11-12-2002, 06:49 PM

all i can think of is that they encode the 9 bit ugo=rwx permission mask in the three low-order digits and suid/sgid/sticky plus some other information in the three high-order digits...

i grok that 120xxx means 'symbolic link' ...

./System/Library/Frameworks/Cocoa.framework/Cocoa 120755

$ ll /System/Library/Frameworks/Cocoa.framework/Cocoa

lrwxr-xr-x 1 root wheel 22 Sep 25 09:20 /System/Library/Frameworks/Cocoa.framework/Cocoa -> Versions/Current/Cocoa

yep. they changed the 'perms' mask from one rev to another...

$ lsbom -p fm /Library/Receipts/*/contents/archive.bom | grep hfs.fs/hfs.util
./System/Library/Filesystems/hfs.fs/hfs.util 104755
./System/Library/Filesystems/hfs.fs/hfs.util 100755

thatch · 11-12-2002, 07:41 PM

Some more poking around with this and I can see that a five digit combination relates to a directory, as in:

Code:

./System/Library/PrivateFrameworks/SecurityHICocoa.framework/Versions/A
/Resources/English.lproj/ChangeKCSettings.nib    40755

...and a six digit combo is just a file:

Code:

./System/Library/PrivateFrameworks/SecurityHICocoa.framework/Versions/A
/Resources/English.lproj/ChangeKCSettings.nib/objects.nib        100644

...and as you pointed out, if the six digit combo has a 2 after the 1 from left to right, it's a sym link:

Code:

./System/Library/PrivateFrameworks/SecurityHICocoa.framework/Versions/Current  120755

So, we've got two digits to the left of our old four digit absolute mode now. And we know that of those, 10 is a file, 4 is a directory, 12 is a symlink. I wonder what else could happen?

mervTormel · 11-12-2002, 08:08 PM

hmm, getting there, but we stray...

100755 means -rwsr-xr-x == an SUID executable

106555 means --r-sr-sr-x == an SGID executable

120755 means lrwxr-xr-x == a symlink

41777 means drwxrwxrwt == sticky bit on the dir

or, something like that.

thatch · 11-12-2002, 09:01 PM

mT,

Yes, I do get all that. Perhaps I wasn't wording my findings very well. It's the first one or two digits from left to right that are new to me. The last four digits are the old absolute mode and haven't changed in meaning.

Since this is all octal, there must be more to it than the three discovered patterns; 10 = file, 12 = symlink, and 4 = directory; or so I am thinking.

Just for yucks, I booted up in 10.1.5 and found this numbering system did exist there although I didn't find a directory or symlink in those .bom files, I guess because I didn't remember any of their names closely enough. For instance, I couldn't find any hfs.* files in any of the receipt packages' .bom files. And I'm running on empty now and need to recharge a bit.... it's been a long day for me. But I'll be back to learn more about this.

I hope this hasn't gotten too far off topic in this thread. My pardons if so. And thanks for hanging in there with me.

silicondiode · 11-12-2002, 09:07 PM

i ran the repair last night, this dir crawl is 30 secs old...

Code:

[elmer2:Library/Filesystems/hfs.fs] scott% dir
total 104
drwxr-xr-x   7 root  wheel    238 Nov 12 13:08 .
drwxr-xr-x  11 root  wheel    374 Oct 31 19:29 ..
drwxr-xr-x   6 root  wheel    204 Oct 22 04:17 Contents
drwxr-xr-x  16 root  wheel    544 Sep  7 04:32 Encodings
-rw-r--r--   1 root  wheel      7 Nov 12 13:08 hfs.label
-rw-r--r--   1 root  wheel      3 Nov 12 13:08 hfs.name
-rwxr-xr-x   1 root  wheel  43728 Nov 11 17:31 hfs.util

looks pretty standard.

11-12-2002, 09:26 PM

My update is taking forever on a dual 1 gig. It's been sitting with about 1/8" left in the installing progress bar for the last 30 minutes. It didn't take that long on my iBook. I'm about ready to pull the plug on this one.

mervTormel · 11-12-2002, 09:52 PM

Quote:


	Originally posted by thatch Yes, I do get all that. Perhaps I wasn't wording my findings very well. It's the first one or two digits from left to right that are new to me. The last four digits are the old absolute mode and haven't changed in meaning...

ahh... i think you're assuming that this reflects that there is a new chmod mode notation.

that is not the case; chmod still uses a four octal digit numeric mode specifiers.

i think it is the case that a .bom file has overloaded values in the high-order 'mode' value. see man lsbom and man bom and note that we are not privvy to how the encoding of the mode is made.

here's a little experiment...

Code:

$ ll

drwx------    2 merv     staff    68 Nov 12 18:34 d1/
drw-rw-rw-    2 merv     staff    68 Nov 12 18:34 d2/
dr-xr-xr-x    2 merv     staff    68 Nov 12 18:34 d3/
-rwxrwsrwx    1 merv     staff     0 Nov 12 18:34 f1*
-rw-rw-rw-    1 merv     staff     0 Nov 12 18:34 f2
-r-sr-xr-x    1 merv     staff     0 Nov 12 18:34 f3*
lrwx------    1 merv     staff     2 Nov 12 18:38 l1 -> f1*
lrwx------    1 merv     staff     2 Nov 12 18:38 ld1 -> d1/

$ sudo mkbom ../bom this.bom

$ lsbom -p fmM this.bom 
.       40700   drwx------ 
./d1    40700   drwx------ 
./d2    40666   drw-rw-rw- 
./d3    40555   dr-xr-xr-x 
./f1    102777  -rwxrwsrwx 
./f2    100666  -rw-rw-rw- 
./f3    104555  -r-sr-xr-x 
./l1    120700  lrwx------ 
./ld1   120700  lrwx------ 
./this.bom      100644  -rw-r--r--

you could carry out the permutations here, and make files for the remaining types to see the effect:

b Block special file.
c Character special file.
s/p Socket link/named pipe.
w Whiteout.

thatch · 11-13-2002, 02:59 AM

silicondiode,

Yes, your output looks pretty standard. It seems that repair permissions after the 10.2.2 update has unset the SUID bit for the hfs.util file.

mT,

Actually, I thought that there might be some new numbering system with regard to bom and lsbom that had octal values like chmod; that based on our earlier posts here. And who knows why the Repair Permissions in Disk Utility show decimal numbering in this instance rather than absolute (octal) or symbolic mode. Anyway, that's what sparked my interest in all this. Your experiment clarifies it all very well. We aren't privy to what those values are other than our own findings, as you had said from the man pages. Well done!

I don't know enough about all the other remaining permutations you mentioned to follow up though, and what that experiment might yield. But I'm willing to tinker about with it to find out. However, I may have to come back to that again later since it is getting late. Thanks for opening my mind to all this nerdy trivia for now. I do find it enjoyable.

thatch · 11-15-2002, 03:43 AM

Okay, I haven't had much time for this but I can tinker with it a bit piecemeal-like. I have only very limitted experience with these special files and I can only create the named pipe out of the bunch because the other ones have a need for the major and minor in their arguments and I don't know about what values to use there for a dummy file. So, here's what I tried with just a named pipe:

Code:

mkdir Desktop/testdir
cd Desktop/testdir/
mkfifo testpipe

ll
total 0
drwxr-xr-x    3 thatch staff         102 Nov 15 00:14 .
drwx------    4 thatch staff         136 Nov 15 00:12 ..
prw-r--r--    1 thatch staff           0 Nov 15 00:14 testpipe

sudo mkbom ../testdir/ test.bom
file 'testpipe' is an unknown file type
can't read ./testpipe. skipping...

l
total 36k
-rw-r--r--    1 root     staff         34k Nov 15 00:14 test.bom
prw-r--r--    1 thatch staff           0 Nov 15 00:14 testpipe

lsbom -p fmM test.bom
.       40755   drwxr-xr-x 
./test.bom      100644  -rw-r--r--

...well, I didn't get too far. I've been reading man pages and texinfo for mkfifo and mknod but am stuck. What to do next?

gsdali · 11-15-2002, 02:31 PM

upgrading to 10.2.2 has killed my keychains and my ability to create keychains. It has also zapped my ability to mount disk images giving an error code of 32 (Broken pipe).

Is this a permissions issue and if so how do I fix it.

thatch · 11-15-2002, 02:42 PM

gsdali,

Try running the Repair Disk Permissions part of Disk Utility on and from your boot drive.

Launch Disk Utility, click on the first aid tab, select your boot volume from the column on the left and then click Repair Disk Permissions. It will take some time but should fix you up. Post back your results.

gsdali · 11-15-2002, 02:50 PM

Rather alarmingly Disk Utility sees "0 Drives and 0 Volumes".

gsdali · 11-15-2002, 02:57 PM

further to that I've just noticed that cds no longer mount. There's been one in my drive since I upgraded and I've only just noticed that its never mounted.

help!!!!

gsdali · 11-15-2002, 03:00 PM

is there a way of using fsck to fix this.

hayne · 11-15-2002, 03:15 PM

gsdali:
First off, you should remove the CD from your cd drive so we can be sure that this is not causing the problem with Disk Utility some how.

When you say that Disk Utility sees 0 drives, do you mean that no drives show up (as icons) on the left side of the Disk Utility window?

thatch · 11-15-2002, 03:20 PM

To remove the CD, reboot and hold down the mouse button until the CD ejects.

mervTormel · 11-15-2002, 03:20 PM

thatch, file modes:

Code:

1 4 0 6 6 4
\ / | | | |
 |  | | | |------ other access
 |  | | |
 |  | | |-------- group access
 |  | |
 |  | |---------- user access
 |  |
 |  |----- special modes: SUID = 4, SGID = 2, sticky bit = 1;
 |         codes are summed if more than one is set, e.g.,
 |         SUID & SGID = 6
 |
 |----file type: named pipe = 01, char dev = 02, dir = 04,
      block dev = 06, reg file = 10, symlink = 12, socket = 14

from "Essential System Administration, 2nd edition" by Aeleen Frisch, O'Reilly

thatch · 11-15-2002, 03:34 PM

Excellent stuff mT! Where did you find this? Or was it just figured out by testing? Thanks for passing it on.

I still would like to continue the experiment too, when you have time to hint me along, of course.

Edit: Ooops, sorry, I didn't read slowly enough to see where you found this info.

11-12-2002, 04:42 PM	#41
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	aha! well, you'd think, in this case, it means "special ed" perms, but in examining the bom entry, it becomes clear... $ lsbom -p fm /Library/Receipts/MacOSXUpdate10.2.2.pkg/Contents/Archive.bom \| grep hfs.fs/hfs.util ./System/Library/Filesystems/hfs.fs/hfs.util 100755 100755 octal == 33261 decimal __________________ On a clear disk, you can seek forever.

11-12-2002, 05:07 PM	#42
thatch All Star Join Date: Jan 2002 Posts: 534	mT, Excellent! But I had thought that 4755 was the octal number. So, I am not computing correctly somehow. However, I had thought about converting octal to decimal and visa versa before. Maybe I should go back to special ed to find the equation. ... I had a look at this which is from my 10.2.1 install: Code: lsbom -p fm /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom \| grep hfs.fs/hfs.util ./System/Library/Filesystems/hfs.fs/hfs.util 104755 Very interesting, eh? Last edited by thatch; 11-12-2002 at 05:18 PM.

11-12-2002, 06:49 PM	#43
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	all i can think of is that they encode the 9 bit ugo=rwx permission mask in the three low-order digits and suid/sgid/sticky plus some other information in the three high-order digits... i grok that 120xxx means 'symbolic link' ... ./System/Library/Frameworks/Cocoa.framework/Cocoa 120755 $ ll /System/Library/Frameworks/Cocoa.framework/Cocoa lrwxr-xr-x 1 root wheel 22 Sep 25 09:20 /System/Library/Frameworks/Cocoa.framework/Cocoa -> Versions/Current/Cocoa yep. they changed the 'perms' mask from one rev to another... $ lsbom -p fm /Library/Receipts/*/contents/archive.bom \| grep hfs.fs/hfs.util ./System/Library/Filesystems/hfs.fs/hfs.util 104755 ./System/Library/Filesystems/hfs.fs/hfs.util 100755 __________________ On a clear disk, you can seek forever.

11-12-2002, 07:41 PM	#44
thatch All Star Join Date: Jan 2002 Posts: 534	Some more poking around with this and I can see that a five digit combination relates to a directory, as in: Code: ./System/Library/PrivateFrameworks/SecurityHICocoa.framework/Versions/A /Resources/English.lproj/ChangeKCSettings.nib 40755 ...and a six digit combo is just a file: Code: ./System/Library/PrivateFrameworks/SecurityHICocoa.framework/Versions/A /Resources/English.lproj/ChangeKCSettings.nib/objects.nib 100644 ...and as you pointed out, if the six digit combo has a 2 after the 1 from left to right, it's a sym link: Code: ./System/Library/PrivateFrameworks/SecurityHICocoa.framework/Versions/Current 120755 So, we've got two digits to the left of our old four digit absolute mode now. And we know that of those, 10 is a file, 4 is a directory, 12 is a symlink. I wonder what else could happen?

11-12-2002, 08:08 PM	#45
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	hmm, getting there, but we stray... 100755 means -rwsr-xr-x == an SUID executable 106555 means --r-sr-sr-x == an SGID executable 120755 means lrwxr-xr-x == a symlink 41777 means drwxrwxrwt == sticky bit on the dir or, something like that. __________________ On a clear disk, you can seek forever.

11-12-2002, 09:01 PM	#46
thatch All Star Join Date: Jan 2002 Posts: 534	mT, Yes, I do get all that. Perhaps I wasn't wording my findings very well. It's the first one or two digits from left to right that are new to me. The last four digits are the old absolute mode and haven't changed in meaning. Since this is all octal, there must be more to it than the three discovered patterns; 10 = file, 12 = symlink, and 4 = directory; or so I am thinking. Just for yucks, I booted up in 10.1.5 and found this numbering system did exist there although I didn't find a directory or symlink in those .bom files, I guess because I didn't remember any of their names closely enough. For instance, I couldn't find any hfs.* files in any of the receipt packages' .bom files. And I'm running on empty now and need to recharge a bit.... it's been a long day for me. But I'll be back to learn more about this. I hope this hasn't gotten too far off topic in this thread. My pardons if so. And thanks for hanging in there with me.

11-12-2002, 09:26 PM	#48
enola Guest Posts: n/a	My update is taking forever on a dual 1 gig. It's been sitting with about 1/8" left in the installing progress bar for the last 30 minutes. It didn't take that long on my iBook. I'm about ready to pull the plug on this one. Last edited by enola; 11-12-2002 at 09:28 PM.

11-13-2002, 02:59 AM	#50
thatch All Star Join Date: Jan 2002 Posts: 534	silicondiode, Yes, your output looks pretty standard. It seems that repair permissions after the 10.2.2 update has unset the SUID bit for the hfs.util file. mT, Actually, I thought that there might be some new numbering system with regard to bom and lsbom that had octal values like chmod; that based on our earlier posts here. And who knows why the Repair Permissions in Disk Utility show decimal numbering in this instance rather than absolute (octal) or symbolic mode. Anyway, that's what sparked my interest in all this. Your experiment clarifies it all very well. We aren't privy to what those values are other than our own findings, as you had said from the man pages. Well done! I don't know enough about all the other remaining permutations you mentioned to follow up though, and what that experiment might yield. But I'm willing to tinker about with it to find out. However, I may have to come back to that again later since it is getting late. Thanks for opening my mind to all this nerdy trivia for now. I do find it enjoyable.

11-15-2002, 03:43 AM	#51
thatch All Star Join Date: Jan 2002 Posts: 534	Continuing experiment... Okay, I haven't had much time for this but I can tinker with it a bit piecemeal-like. I have only very limitted experience with these special files and I can only create the named pipe out of the bunch because the other ones have a need for the major and minor in their arguments and I don't know about what values to use there for a dummy file. So, here's what I tried with just a named pipe: Code: mkdir Desktop/testdir cd Desktop/testdir/ mkfifo testpipe ll total 0 drwxr-xr-x 3 thatch staff 102 Nov 15 00:14 . drwx------ 4 thatch staff 136 Nov 15 00:12 .. prw-r--r-- 1 thatch staff 0 Nov 15 00:14 testpipe sudo mkbom ../testdir/ test.bom file 'testpipe' is an unknown file type can't read ./testpipe. skipping... l total 36k -rw-r--r-- 1 root staff 34k Nov 15 00:14 test.bom prw-r--r-- 1 thatch staff 0 Nov 15 00:14 testpipe lsbom -p fmM test.bom . 40755 drwxr-xr-x ./test.bom 100644 -rw-r--r-- ...well, I didn't get too far. I've been reading man pages and texinfo for mkfifo and mknod but am stuck. What to do next?

11-15-2002, 02:31 PM	#52
gsdali Triple-A Player Join Date: Nov 2002 Posts: 136	upgrading to 10.2.2 has killed my keychains and my ability to create keychains. It has also zapped my ability to mount disk images giving an error code of 32 (Broken pipe). Is this a permissions issue and if so how do I fix it. __________________ -- Ed Lynch-Bell

11-15-2002, 02:42 PM	#53
thatch All Star Join Date: Jan 2002 Posts: 534	gsdali, Try running the Repair Disk Permissions part of Disk Utility on and from your boot drive. Launch Disk Utility, click on the first aid tab, select your boot volume from the column on the left and then click Repair Disk Permissions. It will take some time but should fix you up. Post back your results.

11-15-2002, 02:50 PM	#54
gsdali Triple-A Player Join Date: Nov 2002 Posts: 136	Rather alarmingly Disk Utility sees "0 Drives and 0 Volumes". __________________ -- Ed Lynch-Bell

11-15-2002, 02:57 PM	#55
gsdali Triple-A Player Join Date: Nov 2002 Posts: 136	further to that I've just noticed that cds no longer mount. There's been one in my drive since I upgraded and I've only just noticed that its never mounted. help!!!! __________________ -- Ed Lynch-Bell

11-15-2002, 03:00 PM	#56
gsdali Triple-A Player Join Date: Nov 2002 Posts: 136	is there a way of using fsck to fix this. __________________ -- Ed Lynch-Bell

11-15-2002, 03:15 PM	#57
hayne Site Admin Join Date: Jan 2002 Location: Montreal Posts: 32,473	remove the CD gsdali: First off, you should remove the CD from your cd drive so we can be sure that this is not causing the problem with Disk Utility some how. When you say that Disk Utility sees 0 drives, do you mean that no drives show up (as icons) on the left side of the Disk Utility window?

11-15-2002, 03:20 PM	#58
thatch All Star Join Date: Jan 2002 Posts: 534	To remove the CD, reboot and hold down the mouse button until the CD ejects.

11-15-2002, 03:34 PM	#60
thatch All Star Join Date: Jan 2002 Posts: 534	Excellent stuff mT! Where did you find this? Or was it just figured out by testing? Thanks for passing it on. I still would like to continue the experiment too, when you have time to hint me along, of course. Edit: Ooops, sorry, I didn't read slowly enough to see where you found this info. Last edited by thatch; 11-15-2002 at 03:39 PM.