| PLEX86 | ||
|
Can someone explain this to me 911
Can someone explain this to me 912 On Sun, 20 Feb 2005 13:05:32 -0600, Lin¿nut It's not a bad idea in most situations, but there... Can someone explain this to me 913 done by making logfiles append-only. Man chattr(1) and lcap(8). Nice of you to mention C2, B1 and B2 guidelines. You mentioned in a supports MAC's. A quote from your post: snip If... BTW, you could have also deleted the file, and the encoding would have continued. Can someone explain this to me 914 On Tue, 22 Feb 2005 11:00:48 +0000 (UTC), Rob S. Wolfram No, it's not. Logging is intrinsic to the kernel and cannot be turned off. If you had physical access, you could shut down the... On a traditional Unix filesystem, a file is "really" named by device and inode number. A directory is basically a file maintained by the system that contains a mapping from names to inode numbers. One of the fields in the inode is a reference count of how many directory entries refer to the file. When that reference count goes to zero, the file is deleted. Can someone explain this to me 916 That's a function of the design of the environment. IMO it is a totally misdesigned environment; furthermore if such an environment is *really... So, first let's consider what you did. Your encoder created a file. Let's say the name was "foo". When it did that, the system allocated an inode for the file. Let's say that is inode 108. The system wrote an entry in your current directory that said "foo is inode 108". When you renamed the file, say to "bar", all that happened was the system changed the directory entry to say "bar is inode 108". If you delete the file, the system would remove the directory entry, but it would see that a program still has it open (basically, the in-memory reference count would still be non-zero, because the program has a reference), so the file would continue to exist. It would simply not have a name anymore, so no one else could open it. When the encoder exists, the system will see that no one is using that inode, and the file will go away. If instead of renaming or deleting the file, you made a link ("ln foo bar"), what would happen is that the system would make another directory entry ("bar is inode 108"), and the reference count on disk would go up to 2. The file would now have two names: "foo" and "bar". That's a hard link. If you made a symbolic link ("ln -s foo bar"), the system makes a new file, whose contents are the string "foo", and it is marked as being a symbolic link. The reference count for inode 108 is not changed. A directory entry "bar" is made for that new file. When the system is processing a file name, and gets to "bar", it sees that the file is a symbolic link, and reads it to get the string to subsbreastute, so it ends up getting the name "foo", looks in the directory to see what inode has that name, and gets that file. So, if you make a symbolic link to "foo", and then delete "foo", the link stops working, even if there is a program keeping the file open. The key thing to remember is that "foo" is not the file--it is just a name for the file, only used when someone needs to refer to the file by name (such as when opening it), and not needed or used for things like reading and writing the file. -- --Tim Smith
|
||||||||