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. 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* 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 (and 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 the directory that contains the file name, you can delete the file name from the directory. "What if I want to delete a sub-directory from a directory?" 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. 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 into the directory. Why?) 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 an entry in your current directory, and so you must have X perms on the current directory to use ".." to go up one level. You need X permission on your parent directory to pass through it using name "alex" to directory named "alex". (Remember - names are separate from the things they name!) You need X permission on directory "alex" to pass through using name "demo" to the actual file inode for "demo". You need R permissions on the 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 directory named "home". (Remember - names are separate from the things they name!) You need X permission on the "home" directory to pass through it using name "alex" to directory named "alex". (Remember - names are separate from the things they name!) You need X permission on directory "alex" to pass through using name "demo" to the actual file inode for "demo". You need R permissions on the 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?" Almost everything else, except the name, is part of the inode that holds the file data: owner, group, access and modify times, permissions, size, etc. None of this appears in the directory; it is all kept in the file inode along with 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 *with the file data*, not in the directory. 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*. 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 what 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, us 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? Sort the output to make the 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? - 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 the single directory, not the contents of the directory.