Bob Supnik lurking? (simh PDP11 question)

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Sun Oct 3 21:22:33 2004

It was thus said that the Great Ron Hudson once stated:
>
> On Oct 3, 2004, at 6:13 PM, Stephane Tsacas wrote:
>
> > 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)

  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.

> 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.
Received on Sun Oct 03 2004 - 21:22:33 BST