3 Oct
2004
3 Oct
'04
2:22 p.m.
It was thus said that the Great Ron Hudson once stated:
On Oct 3, 2004, at 6:13 PM, Stephane Tsacas wrote:
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.
On unix renaming a file just updates the
directory which contains the
file. Also, from the process point of view, an opened file is a small
integer, so the process can't be notified that the opened file has
been renamed or even deleted (in that case the file will still use
blocks on the filesystem until the process dies, you just lose access
to it from outside the process).
Stephane
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?
Yes. Both hard and soft.
And what if simh closes and opens the file as needed?
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.