Week 3 Notes for DAT2330 - Ian Allen Supplement to Text, outlining the material done in class and lab. Remember - knowing how to find out the answer is more important than memorizing the answer. Learn to fish! RTFM![*] ([*] Read The Fine Manual) Look under the "Notes" button on the course web page for these study notes for the Linux textbook: chapter4.txt (the Linux File System) Complete these Floppix Labs on http://floppix.ccai.com/ Floppix Lab 3: logical organization of the Linux file system Floppix Lab 4: navigating the file system Floppix Lab 5: directory listings Floppix Lab 6: directory commands Floppix Lab 7: file commands ------------------------------------------ Unix/Linux File System - (the weird parts) ------------------------------------------ Read the text (Chapter 4) for the non-weird parts. All the *diagrams* showing file systems and links in the text are wrong and range from confusing to seriously misleading. Here's the truth. Names are stored in directories, not with the things to which the names refer. The text makes the error of putting the names on the things that are being named. That is misleading and the cause of many misunderstandings about Unix/Linux files and directories. When you look at a Unix pathname, consider that the slashes separate names of pathname components. All the components to the left of the rightmost slash must be directories, including the "empty" directory name to the left of the leftmost slash. For example: /home/alex/names In the above example, there are three slashes and therefore four pathname components. The "empty" name in front of the first slash is the name of the ROOT directory. The ROOT directory doesn't have a name. (Some books get around this by calling the ROOT directory "slash" or "/". That is wrong. ROOT doesn't have a name.) Inside the ROOT directory is the name of the "home" directory. Here is the correct diagram for Figure 4.4 on page 70. Note that the names for things are one level *above* the things to which the names actually refer: +------+ | home | This box is the ROOT directory. It has the name "home" in it. +------+ The *directory* "home" is not here; only the *name* is here. | The ROOT directory itself does not have a name! | +------+ | alex | This box is the "home" directory. It has the name "alex" in it. +------+ The name "home" isn't here; it's up in the ROOT directory. | | +----------------------------------+ This box is the "alex" directory. | names | temp | literature | demo | It has many names in it. Note: +----------------------------------+ the dir name "alex" isn't kept here. | | | | The name is up in the "home" directory. | | | | *----* *----* | *----* These are disk nodes containing the |data| |data| | |data| data for each of the files named in *----* *----* | *----* the directory "alex". No names are here! +-------+ | promo | This box is the "literature" directory. +-------+ It has the name "promo" in it. | | *----* This is a disk node (inode) containing the |data| data for the file named "promo". The name "promo" *----* is one level above, in the "literature" directory. To follow a path such as /home/alex/literature/promo just walk the tree. Start with the ROOT directory (which doesn't have a name, since it does not appear in any parent directory) and look for the first pathname component ("home") inside. Let's trace the pathname: Look in the ROOT directory for the *name* of the first pathname component: "home". We find the name "home" inside the ROOT directory. Follow the link in the ROOT directory that leads from the *name* "home" to the actual *directory* that is "home". (Note how the names are separate from the things they name. The actual *directory* is nowhere near its name.) In the *directory* that has the name "home", look for the *name* "alex". We find it. Follow the link in the "home" directory that leads from the *name* "alex" to the actual *directory* that is ALEX. (Again, the *name* "alex" is separate from the *directory* "alex".) In the *directory* that has the name "alex", look for the *name* "literature". We find it. Follow the link in the "alex" directory that leads from the *name* "literature" to the *directory* that is "literature". (Again, the *name* "literature" is separate from the *directory* "literature".) In the *directory* that is "literature", look for the *name* "promo". We find it. Follow the link in the "literature" directory that leads from the *name* "promo" to the *file* that is "promo". (Again, the name is separate from the thing it names, so the name is not part of the data that makes up the file.) You now have the disk node (inode) that is your file data. If the file has appropriate permissions, you can read it or write it. "What permissions do I need on a file to delete it from a directory?" None! You don't even have to own the file. You need *write* and *search* permissions on the *directory* that contains the *name* of the file, to remove the *name* of the file from the *directory*. (When all links to a file are gone, the file is reclaimed by the system.) Removing a file is a directory operation that deletes a name (a name is a link); it has absolutely nothing to do with the permissions or owner on whatever the link happens to point to. If you can write and search the directory that contains the file name ("wx" permissions on the directory), you can delete the file name (the link) from the directory. "What if I want to delete a sub-directory from a directory?" You need "wx" permissions to remove the sub-directory name from the directory, just as if the name pointed to a file. However: You can only delete from a directory a name that points to a sub-directory if that other sub-directory is *empty*. If you don't have permission to empty out that sub-directory, you won't be able to delete its name from its parent directory, even if you have permissions on the parent directory. Scenario: Alex creates, in his home directory, a sub-directory "foo" with write permissions for everyone. Ian creates a sub-sub-directory "foo/bar" with permissions only for Ian, and then Ian creates a file "foo/bar/haha". It is now impossible for Alex to delete the foo sub-directory from his own home directory, because Alex cannot empty out and remove the sub-sub-directory foo/bar, because only Ian has permissions to remove the file name foo/bar/haha from the foo/bar sub-sub-directory. (Only Ian can write the sub-sub-directory named foo/bar.) Alex is stuck with the foo sub-directory in his account. Alex can rename it (e.g. mv foo .junk); but, he can't delete foo until Ian makes it empty. Only empty directories may be deleted. Directories Rule (p.81): "X" permissions on a directory mean you can pass "through" the directory to access a thing if you already know the name of the thing you want to access. ("Search permission.") "R" permissions on a directory mean you can see the names in the directory. The output on the bottom of page 81 is wrong. You can't get a *long* listing of the files in a directory ("ls -l") unless you have X permissions to pass through the directory to find out what kind of nodes the names in the directory represent. You can get a short listing of just the *names* in a directory without needing X permissions. In other words: If you don't have R permission, you can't see the names inside a directory. If you happen to know some names, and you have X permission, you can go *through* the directory to get to the things pointed to by the names that you know. If you don't have X permission, then you can't *get to* the files, even if you have R permission and can see their names. Names are separate from content; you may be able to see the names without being able to pass through the directory to go get the content. "I'm logged in as idallen over in /home/idallen. What permissions do I need to read ../alex/demo?" This is a *relative* pathname. It starts with the current directory and goes up from there. You need X permission on the current directory "." ("." is /home/idallen) to let you pass through using name ".." to your parent directory. In this example, your parent directory would be "/home". ".." is a relative pathname, meaning it starts with an entry in your current directory, and so you must have X perms on the current directory to use the name ".." in the current directory to go up one level. You need X permission on your parent directory ("home") to pass through it using name "alex" to the inode that is the actual directory named "alex". (Remember - names are separate from the things they name!) You need X permission on directory "alex" to pass through it using name "demo" to the actual file inode for the name "demo". You need R permissions on the "demo" file inode to read the data. "I'm logged in as idallen over in /home/idallen. What permissions do I need to read /home/alex/demo?" This is an *absolute* pathname. It ignores the current directory. Nothing about the current directory is needed. The path search starts from the ROOT directory. The following sequence is identical, no matter what directory is your current directory: You need X permission on the ROOT directory to pass through it using name "home" to the inode of the directory named "home". (Remember - names are separate from the things they name!) You need X permission on the inode of the "home" directory to pass through it using name "alex" to inode of the directory named "alex". (Remember - names are separate from the things they name!) You need X permission on inode of the directory "alex" to pass through it using name "demo" to the actual file inode for "demo". You need R permissions on the "demo" file inode to read the data. "The *name* of a file is separate from the actual file data. What information *is* kept with the file data?" Everything else, except the name, is part of the inode that holds the file data. This means: owner, group, access and modify times, permissions, size, etc. None of this information appears in the directory; it is all kept in the file inode along with the pointers to the disk blocks that contain the actual file data. No matter what name you use to find a file's inode on disk, the file has the same owner, group, permissions, etc. because one copy of all that information is kept in the inode *with the file data*, not in the directory. The only things you will find in a Unix directory are names and inode numbers - everything else is in the inode of the file. Explain this sequence (removing X permission on a directory): $ mkdir /tmp/idallen $ cd /tmp/idallen $ touch a b c d $ ls a b c d $ chmod -x . $ ls ls: .: Permission denied $ ls .. ls: ..: Permission denied $ ls a b c d ls: a: Permission denied ls: b: Permission denied ls: c: Permission denied ls: d: Permission denied $ ls /tmp/idallen a b c d $ ls -l /tmp/idallen ls: /tmp/idallen/a: Permission denied ls: /tmp/idallen/b: Permission denied ls: /tmp/idallen/c: Permission denied ls: /tmp/idallen/d: Permission denied $ ls /tmp/idallen/a ls: /tmp/idallen/a: Permission denied $ ls -l /tmp/idallen/a ls: /tmp/idallen/a: Permission denied $ chmod +x . chmod: .: Permission denied $ chmod +x /tmp/idallen $ ls a b c d Note how "ls -l /tmp/idallen" can find the *names* in the directory (because it can read the directory); but, it can't go *through* the directory to actually look at what the names point to! So it can't tell you anything about what the names actually *are*. An "ls -l" long listing needs to know what the names *are* - it requires more permissions that a plain "ls" that only needs to know the names, not what they are. And now study this one (removing R permission on a directory): $ mkdir /tmp/idallen $ cd /tmp/idallen $ touch a b c d $ ls a b c d $ chmod -r . $ ls ls: .: Permission denied $ ls .. file1 file2 file3 idallen $ ls a b c d a b c d $ ls /tmp/idallen ls: /tmp/idallen: Permission denied $ ls -l /tmp/idallen ls: /tmp/idallen: Permission denied $ ls /tmp/idallen/a /tmp/idallen/a $ ls -l /tmp/idallen/a -rw-r--r-- 1 idallen users 0 Jan 28 13:43 /tmp/idallen/a $ chmod +r . $ ls a b c d Without read permission on the directory, we can't find out what names are in the directory. But, if we already know some of the names in the directory we can go through the directory to get the details about the inodes that the the names point to, because we still have X (search) permission. --------------------- A Study in File Links --------------------- What is the "link count" field displayed by the "ls -l" command? What causes a file's link count to increment? What happens when a file's link count becomes zero (text p.84)? On ACADAIX, use the "-i" option to "ls" on this set of files: $ ls -li /usr/bin/*sh Note the inode numbers (text p.84) of each name in this directory. Which names are really the same file? (The inode numbers will tell you!) Sort the output to make the inode numbers that are the same come together and be easier to see: $ ls -li /usr/bin/*sh | sort Look at the entire /usr/bin directory and note which names in this directory are actually pointers (hard links) to the same file: $ ls -li /usr/bin | sort | more Where is the name of the file "zsh" stored? Where is the name of the directory "bin" stored? Where is the name of the directory "usr" stored? --------------------- Links and Directories --------------------- - What command and options are needed to see the access permissions and link count of a directory, instead of the *contents* of a directory? (text, p.81) - When you are inside a directory, what is the name you use to refer to the directory itself? (This name works inside any directory.) - How many links does a brand new, empty directory have? Why isn't it just one link, as it is for a new file? (In other words, why does a new file have one link and a new directory have more than that?) - Why does creating a sub-directory in a directory cause the directory's link count to increase by one for every sub-directory created? - Why doesn't the link count of the directory increase when you create files in the directory? - Give the Unix command and its output that shows the inode number and owners of the following directories: a) your HOME directory b) the /bin directory c) the root directory Note: Show only one line of output for each single directory; do not show the contents of the directory. Use a command (and options) that will show only the directory itself, not its contents.