PLEX86  x86- Virtual Machine (VM) Program
 Plex86  |  CVS  |  Mailing List  |  Download  |  Computer Folklore     

Can someone explain this to me 911


VPN Service Provider

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


Linux | Previous | Next

Can someone explain this to me 912

Linux Advocacy Newsgroups

Red Hat predicts rest of Solaris 910