Posted on by mwhybark

the root of the matter

the man page for hdid explains the problem:

Beware that an image you have created and attached is considered an unknown removable device. For HFS filesystems on such a device, being unknown to the system means that the on-disk ownership of files and directories are ignored by default. On 10.2, they were dynamically replaced with the owner of /dev/console and the group unknown (gid 99). On 10.3, the group remains unknown, but the owner is whoever is currently accessing the file (joe sees that he owns the file when he looks; mary sees she owns it whenever she looks). Owners can be enabled for a particular volume permanently (see disktool/”get info” in the Finder) or temporarily (see EXAMPLES section of hdiutil(1)). Aside from whether owners are enabled, being removable means that disk arbitration will mount any volumes with special options such as nosuid.

However, this does not identify the original file ownership settings nor explain the criteria for those files that did not get remapped.

Posted on by mwhybark

Texting

To save an excel file as tab-delimited text into a specific subdirectory, these are the keystokes I have found to be required for this single operation in Office Excel 2003 under Win XP:

alt-F, A
Tab, T, T, Return
Shift-Tab, Shift-Tab, Up arrow, Down arrow, Return
Alt-S, Return, Y, Control-W, N

That’s fifteen keystrokes for something that should take one click. Further providing me amusement is the employment of not one, but TWO meta-keys to provide menu-command and window-control access.

Experienced Excel users will also recognize that the use of the “Y” and “N” keys in the final line of this control sonnet are a negative agreement and a positive agreement to the gentle and concerned ministrations of the save-dialog wizard, which forces the user to respond consecutively “Yes” and “No” to two similar questions having to to with Excel data-formats and the lack of support for them to be found in text files.

Posted on by mwhybark

Buffer Overrrun

Before I forget, my current understanding of the problem and repair procedure for Odysseus is:

Problem definition: when the underlying copy tool used by CCC to create images, “ditto,” does its’ thing, in certain circumstances, file ownership records are changed to 99 from the appropriate ownership status. CCC fora indicate this problem is associated with files created under OS9 and therefore outside of the permissins and ownership management protocols of OS X. In my case, this clearly affects files that have nothing to do with OS9.

User ID 99 is a special ID which causes the files to report, falsely, that they are owned by whatever process it is that is attempting to determine ownership. Determining the proper ownership of these files and resetting them to the correct User ID is the resolution. The problem that arises is isolating and identifying the appropriate and accurate ownership setting. It may actually be impossible to do so, if the UID 99 has been assigned to files which should belong to more than a single user ID or process.

1. Restore from backup via imaging.

2. Hand restore any User directories and preferences. I beleive I may attempt to hand restore Applicaions as well, but if that fails, I can figure out any apps that were updated in the day or two we’re looking to restore to.

3. Check for the UID problem.

4. If found (it will be), dig out the initiall installation disks that came with the unit. Perform an install using the archive and restore user prefs option.

This should resolve all system-level UID and perms errors, leaving only any issues associated with user-installed applications and files in the User directory hierarchy. THe files in the User directory, in theory, can then be recursively set to belong to the user associated with that directory.

Any remaining UID errors can be isolated on an application by application basis, presumably via reinstalls.