On Oct 3, 2004, at 6:13 PM, Stephane Tsacas wrote: Ok, What do you mean... It seems to me your saying that if I rename the file and name a new one in it's place the running process (simh) will continue to access the old file..(perhaps by inode) Still true if I use links? And what if simh closes and opens the file as needed?

On Sun, 3 Oct 2004, Ron Hudson wrote: The directory entry ("foo.x") simply points to the inode that is the file. So once a process has a file opened, it references the file via the inode, so renaming the file has no effect. THe only "danger" is if the process needs to re-open the file (after closing it) and you've renamed it, but that's obvious, huh. (This is a secure way to handle temporary files: a process opens a file then deletes (unlinks) it, as long as the file is open, it (the inode) continues to exist; it will disappear when all references to the inode disappear, eg. you close the file. The advantage is, since the file doesn't have a name (in the directory) no other process can open it.)

It was thus said that the Great Ron Hudson once stated: Yes, exactly (only once you open a file, you access it via a handle, an integer value that only has meaning to the kernel). The file can be deleted (and it's name and inode will be removed from the disk) but it will still exist for the process that has it opened (the datablocks still exist on the disk). A file is only truely removed when there are no more processes that have it open. Yes. Both hard and soft. Until the process calls close() on a file, it will "exist" as far as the process is concerned (with respect to the file being renamed/deleted as the file is open). If it helps, think that once a process does the following: fh = open(somefile,mode); it establishes a communication channel with the file, and it can do anything (permissions and mode granting) to the file without having to worry about it disappearing underneath it [1], until the following: close(fh); You can play around with this using two shells on the same system. In shell 1, do: % mkdir /tmp/foo Then in shell 2, do % cd /tmp/foo % ls -l /dev >bar % more bar When you get a "more" prompt, then go back to shell 1 and type: % /bin/rm -rf /tmp/foo Then go back to shell 2. You can still page through the file all you want. Once you quite more though, if you do a % ls -l you'll see the directory is now empty. You can't create any more new files in the directory but a pwd will still show you in "/tmp/foo". It technically still exists on disk (until you exit out of that directory) but you can't get to it anymore. -spc (this behavior can be used to create temporary files ... ) [1] In some cases, it can, like NFS crashing or something, but the calls read(), write(), ioctl(), fcntl(), select() (and any others that use a file handle I've forgotten) will return an error.