The access time may or may not actually get set on a file when it is accessed. Write-locked volumes, such as CD-ROMs and writelocked floppy disks, cannot change any bits at all, therefore access times are not updated.
MS DOS (ms windows), and HFS (old macos) volumes, for instance, have no access times in their file headers. Usually the modify time will be substituted when you ask the filesystem, so that the icons always appear in one color in Interrogator.
Even Unix filesystems, which have an access time in their file headers, might not maintain them. Since the access time must be stored on the disk, and might be changed upon every read access, this degrades performance, sometimes by quite a bit. Usually, there's an option to turn this off. In Linux, for instance, you can mount a volume with the noatime option, or specify it in the fstab file.
Different kinds of filesystems can have their own ideosyncrasies and interpretations. Sometimes a write is considered an access, sometimes not. Some versions of the Reiser filesystem never update the atimes on directories, although they do on regular files and symlinks.
Because Interrogator accesses directories and symlinks in the process of doing its job, this can cause access times to be spoiled. Interrogator attempts to indicate this by coloring the outlines in gray, because otherwise, the yellow coloring would be distracting and misleading.
You should do some experimentation on your volume before you trust the times,
especially access times, that you see.
For instance, let's say there's a user throckmorton in a group nerds. You have a file secretInfo that you want everybody in the group nerds to read, EXCEPT throckmorton. With the normal Unix rules, you could set the group to nerds, the owner to throckmorton, and give it a protection like this:
$ chown throckmorton secretInfo
$ chgrp nerds secretInfo
$ chmod o= secretInfo # set others to no access
$ ls -l secretInfo
-rw-r----- 1 throckmorton nerds 5940 Oct 28 10:28 secretInfo
$ chmod u= secretInfo # set user owner to no access
$ ls -l secretInfo
----r----- 1 throckmorton nerds 5940 Oct 28 10:28 secretInfo
$ chmod g=rw secretInfo # set group access to read & write
$ ls -l secretInfo
----rw---- 1 throckmorton nerds 5940 Oct 28 10:28 secretInfo
The problem with this scheme is that throckmorton now OWNs it and can give himself permissions back! Not what you wanted.
You could instead use the (Solaris) command setfacl to set throckmorton's permissions so that he can't read it:
$ setfacl -m u:throckmorton: secretInfo # set throc to no access
$ ls -l secretInfo
-rw-rw----+ 1 root nerds 0 Oct 28 10:28 secretInfo
The plus sign tells you that there's more information: ACL information to be exact.
ACL support comes for free with Solaris, but with Linux you must format your partition with a filesystem type that supports ACLs.
The exact rules for ACLs are involved and change from one ACL system to another. On Solaris, see man getfacl, man setfacl.
MacOS aliases are actually much more complex than Unix symlinks. Whereas symlinks have a directory name for each pathname component (just a character string between slashes), an alias carries both a name and a directory ID (effectlvely like an i-node number) for each path component. The ID typically takes precedence over the name in Mac OS 9 and early versions of Mac OS X, but since X.2 the name takes precedence.
The earlier system with the ID taking precedence introduced some interesting phenomena. If you rename files or or directories, you can cause a symlink to target a different file that is moved into place, whereas an alias may follow the actual file targeted, even if renamed and moved around. Only if that file, or an enclosing directory, disappears will the original name take effect. This can be confusing for the experienced user accustomed to symlinks. It is designed to help out the more common users who might accidentally damage their system. The more recent change makes these situations more intuitive.
As you might imagine, MacOS programs have trouble understanding symlinks, and Unix programs have trouble understanding aliases. To a Unix program, an alias appears to be an empty regular file. All the alias information is in the resource fork, which is ignored. A MacOS attribute bit indicates that it is an alias file, but only MacOS programs know to look for this attribute.
To a MacOS program, a symlink appears somewhat like an alias, in that opening the file results in the opening of the targeted file rather than the originally named symlink file. If the program attempts to treat the file as an alias, however, all sorts of things will go wrong because it doesn't have the usual alias features.
For example, the word "Sarah" would be encoded as follows:
characters: |
S | a | r | a | h |
bytes: |
53 | 61 | 72 | 61 | 68 |
Using 8 bit bytes, there are 256 different codes you can have, for 256 different
characters. Strictly speaking, Ascii text is encoded as numbers from 0 to 127. On
a US keyboard, the printable characters visible on keycaps on the main alphabetic
block constitute this set of characters. The approximate layout of characters is:
0-31: Control characters
48-57: the digits 0-9
65-90: the letters A-Z
97-122: the letters a-z
everywhere else: punctuation
The control characters include Return, Line Feed (sometimes called New Line), Tab, Escape, and a large number of legacy codes.
Because almost all computers today use 8 bit bytes, there are 128 other character codes that can be used for other purposes. During the 1980s, many incompatible systems used these codes for accented letters, extra punctuation, and other typographer's symbols. Localized operating systems used the codes for special alphabets such as Japanese, Russian or Greek.
A popular standard is the ISO Latin-1 set, which encodes most Western European characters. This is common on Unix on English and other western European language systems. A barely compatible take-off is used on MS Windows. MacOS, MS-DOS and some older systems have used their own proprietary systems for English.
For instance, curly quote marks entered into emails in English Windows computers often turn out to be accented vowels on English Macintosh computers, and become Katakana characters in Japanese.
hex code |
decimal code |
MS Windows (US) |
Macintosh (US) |
Unix (Latin-1) |
Japanese (half-width katakana) |
---|---|---|---|---|---|
25 |
37 |
% |
% |
% |
% |
41 |
65 |
A |
A |
A |
A |
5c |
92 |
\ |
\ |
\ |
¥
|
92 |
146 |
’ |
í |
none |
first byte of
|
ae |
174 |
® |
Æ |
® |
a japanese character |
Another popular system is UTF-8, which encodes Unicode characters. This has the capacity to encode all of these systems. For this reason, its use is on the rise. The main barrier is compatibility with current systems, most of which are in transition. Since UTF-8 is a sequence of bytes, it is easier for current systems to support it than original Unicode.
Interrogator Glossary
Copyright (C) 2001-2004 Tactile Interactive Software Inc.
If you find a term that isn't defined here, or any other errors,
please notify us.
Documentation >
Glossary >
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0123456789 punctuation |
|
||||