For example, the PATH environment variable is searched for commands that you enter
at the command line. Let's say your PATH is this:
/home/gina/bin:.:/usr/local/bin:/usr/bin:/bin
So you type in the command "date", and it first searches for a file named
"date" in the directory /home/gina/bin (looks like it's in gina's home
directory), then it searches in your current directory (from the cd commmand), then
it searches /usr/local/bin, then /usr/bin, then /bin. Finally it finds a file in
/bin, which is a program named "date", and it runs that program, which
prints the date.
For example, let's say you want to read the file /etc/httpd/mime.types
- You need search permission in the /
directory in order to locate /etc.
- You also need search permission in /etc to locate /etc/httpd
- And in /etc/httpd to locate /etc/httpd/mime.types.
- Then of course you need read permission on the file mime.types.
This permission says that the kernel can 'search' for a file on your behalf in this directory. It does not give you permission to read the directory yourself and 'search' on your own; you need Read Permission for that.
The combination of Read and Execute permissions yields four useful combinations for a directory:
You can't tell what kind of file they are - directory or symlink or block device - or any dates, any mode bits, or anything else. Interrogator indicates this with a question mark icon for each file-object in the directory. You cannot read any of these files or use any directory inside.
Interrogator indicates this with a message. Initially, only the files . and .. are depicted, and only because Interrogator assumes almost all directories have them. You can type in a name of a file and press Enter to see if it exists. If so, you can use it as normal in Interrogator; if it's a directory, you can open it up or whatever, depending on its own permissions. Interrogator will remember the names you correctly guess in that directory, so that you can use them later. But, without Read permission on the directory, you can never list out the filenames and you can never be assured that there isn't another file beyond what you have guessed.
If you are on a case sensitive filesystem type like ufs or ext, you must guess the case correctly. If on a case insensitive volume type, you can get the case wrong and still get a match.
Search permission also can be used with Write permission, with no Read permission, for instance for an anonymous submission directory. Everybody has permission to add new files and directories, but they can't see what other people have dropped in.
This is very powerful and very dangerous, but not as dangerous as the SUID bit. Often, this bit is automatically turned off for security reasons when you do things like copy the file or tinker with the mode.
On machines that are dedicated to one operating system, this slice system usually takes over the whole physical disk. On x86 systems, often the slice system is embedded in one of the primary partitions.
The term slice has slightly different meanings when used by the different cultures, especially on x86 architectures, so be careful how it is used in your documentation. Typically on Solaris, you have a disk that is divided up into "fdisk partitions" (their word for the four primary partitions), and one of these four gets a disklabel and is divided up into eight (or fewer) "slices". The same situation on BSD is described as a disk with four "slices" (their word for the four primary partitions), and one of these slices has a disklabel that defines up to eight "partitions".
Despite similar origins, Solaris and BSD disklabels are incompatible and mutually ignored. Similarly, their main filesystem type, called UFS in both cases, have evolved away from each other and are unusable by the opposite OS.
SMB is also an acronym used to mean Small and Medium Business, a market category in the computer industry. To add to the confusion, SMBs often use SMB.
In support of sparse files, there's a trick to storing sparse files that have mostly zero bytes. If you simply don't write the file continuously starting from the beginning, whole depletion blocks are omitted from the file storage. They are assumed to be zeros when reading the file back. Files like this are often called 'sparse' even if they don't match the original definition and only have a few small holes. The word's meaning has been appropriated to mean virtually the opposite of its original meaning because really such files are more dense than they would be if not stored with this trick.
One could use this to make a fast text lookup system, for instance. Use the first four characters of the key as the offset into a sparse index file. The content size of the index file should be big enough for four billion entries, but only filled entries would have blocks devoted to them.
Copying these files is tricky because a simple algorithm would just inflate the file to full content size. To compound the problem, there is no definitive way to detect if a particular zero-filled block is real zeros or just a hole. (They are supposed to be equivalent, after all.)
Interrogator, by default, guesses if it's sparse by comparing its depletion and content sizes. (Notice that another compression scheme can trigger this falsely.) If it appears sparse, it will use the sparse algorithm to copy, creating a hole wherever it reads zero blocks (even if it wasn't a hole originally). If it does not appear sparse, it will copy it all contiguously, explicitly writing all zero blocks as normal. (If your file has no zero blocks, the results are identical, if not, the results are still usually mostly indistinguishable.) This is roughly the same thing that the cp command does and is unlikely to cause any problems.
You can micro-manage this by using the K preflag in Interrogator, either ^K on Mac or alt K on X11. Using ^K will force sparse copying if you type it once, or will force non-sparse if you type it twice. This works for either Paste, Duplicate or by drag-and-drop copying.
Unfortunately, files with large zero areas are hard to come by. No text files will qualify because 0 is not used as a character. Compressed files like zip, stuffit, gzip, or even gif, png or jpeg, are unlikely because the compression algorithms would squeeze out anything like that.
You can create a sparse file on the command line with the dd command, do a man dd to see how, or try this example.
echo hello | dd of=spar_tan seek=999
Now compare the content size and depletion size in Interrogator with Full Disclosure mode. If the depletion size is much smaller than the content size, you've made a sparse file.
The trick only works on filesystems that support this; UFS (all flavors) and EXT (all flavors) support this on Linux and Solaris, but HFS filesystems on Mac don't do it, and neither do MS-DOS partitions. (But you can make it work on a Mac by making a UFS disk image in Disk Utility. New Image and then Erase it with Unix File System. Mount it by opening the disk image file, then work inside that volume.)
Special device files do not deplete bytes in the filesystem; usually their header information is used by special low-level system services to do things that can't be done using regular files. Special device files come in many kinds:
The directory /dev has many such special files in it; in Solaris, these are symlinks that point to device files under /devices.
See also
file .
Formerly, this bit also had a meaning when used on executable programs:
the pages of the file would be kept in ram, assuming that multiple people are using it constantly.
Modern virtual memory systems usually manage this automatically,
and therfore this bit is ignored on executables.
This is very powerful and very dangerous.
For instance, if an intruder manages to create a copy of a shell program, or Interrogator,
that's owned by the superuser and has the SUID bit set,
they can run the program to become root,
and any program they run from inside will also run with root privileges.
In other words, they've got root, they can access anything,
and all other security measures on the machine collapse like a house of cards.
Often, this bit is automatically turned off for security reasons when you do things
like copy the file or tinker with the mode.
See also SGID bit.
The superuser's user id is always 0 and user name is
always "root".
You can tell if you are running Interrogator as the superuser, because the background
of all of your windows will be black instead of white.
Attaining root permission is sometimes called getting root.
Some operations, on the other hand, are not referred to the target file. If you delete
the file Marilyn.jpeg, for instance, only the symlink file is deleted, not the original
data. Symlinks usually have little or no depletion, and so you can have a large number
of them without running out of space on your disk.
The target text can refer to a different directory, either relative
to where the symlink file is, or an absolute pathname.
(You cannot use ~ constructs for home directories, however,
because that is just a shell substitution, which also works in
some other programs such as Interrogator.)
For instance, consider the target file /home/nj/NormaJean.jpeg.
Consider these symlink files, that all point to this target file:
/home/nj/Marilyn.jpeg -> "NormaJean.jpeg"
Note that the last one actually has a target that is another symlink; you can chain
symlinks as long as you don't have too many levels. Two or three levels are usually
OK; ten are usually too many.
Symlinks are not required to point to an existing file as a target; they are just
character strings. Symlinks whose targets don't exist are called dangling symlinks.
They aren't very useful - usually they are the result of some problem.
Usually you get such an error message when you try to use them.
Consider these
(possible) dangling symlinks:
You can also have symlinks that are circularly referential or self-referential. These
will eventually give you an error message, although it might take a while for the
OS or whomever to figure out the problem.
/home/nj/Pamela.jpeg -> "Pamela.jpeg"
In some cases, programs are dumb enough to fill up your hard disk with recursive
directories, such as when you try to copy the second example above, or compress it
into an archive, and you end up with concentric Cindy directories.
Symlinks can point to files on other volumes, unlike Hard Links. Symlinks are
NOT symmetric with their targets as with hard links: if you delete the symlink, the
target is unaffected; whereas if you delete a target, the symlink becomes dangling.
See also Hard Link,
alias, man ln
A symlink on Unix actually contains just a short character string that points to
its target. For instance, consider a regular file NormaJean.jpeg, and a symlink file
Marilyn.jpeg which has the target text "NormaJean.jpeg". When you try to
use the symlink file Marilyn.jpeg for reading or writing, the operating system will
redirect to the file NormaJean.jpeg, which actually holds the bytes of data.
/home/pat/mdimaggio.jpeg -> "../nj/NormaJean.jpeg"
/home/pat/mmonroe -> "/home/nj/NormaJean.jpeg"
/home/pat/marym -> "mdimaggio.jpeg"
/home/pat/Marilyn.jpeg -> "NormaJean.jpeg" (no directory)
/home/pat/MarilynM.jpeg -> "../jn/NormaJean.jpeg" (wrong directory)
/home/nj/Bo.jpeg -> "MaryCathleen.jpeg" (no such file)
/home/nj/Cindy -> "/home/nj/"
/home/nj/Veronica.jpeg -> "ConstanceFrancesMarie.jpeg"
/home/nj/ConstanceFrancesMarie.jpeg -> "Veronica.jpeg"
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 |
|
||||