[Oberon] Oakwood Files.Delete

[Michael Schierl]

Hello,


trying to add some details to your excellent description :-)


Am 23.07.2019 um 19:54 schrieb Claudio Nieder:
> Hi,
>
> I do not know how it is in Windows, but this is actually how Unix
> (and thus Linux) has always treated files.

On Windows an application can open files with POSIX semantics, and if
they do so, it will behave the same. As long as any program still has
the file open with Win32 semantics, it won't be deletable, though.

If you have cygwin installed you can try it by doing e.g.

cat >>dummyfile & CATPID=$!

rm dummyfile

ls -l /proc/$CATPID/fd

You will see one of the file descriptors pointing to "dummyfile
(deleted)". Yet the file is nowhere to be seen.

[you can clean up using "kill $CATPID && fg"]

And if the file had some significant size, you can see from disk space
usage that it is still there.

(You can do the same on Linux, and also on other UNIX systems if they
have a /proc filesystem.)

> And indeed one can write
> in Unix a program which opens a file and immediately performs an
> unlink and the file is sort of invisible in the sense, that there is
> no directory entry for it anymore.

I assume every unix sysadmin who had a disk which was full of logfiles
at least once accidentally deleted a logfile (which was still written
to) instead of truncating it and immediately regretted it as now he has
to kill/restart the process that writes the logfile so he can get the
disk space back (and see the log output in the newly created logfile).

> Now at this point I am unsure if it is enough that one of the
> processes performs a close on the file or if all (in case of
> inheritance to child processes) need to close it (termination of the
> process will close it implicetly).

The kernel keeps a link counter for each file. Each hard link on the
disk (there can be more than one) add one to the counter, and every
process who has the file open adds one as well. So if more than one
process has the file open (either by opening it individually or by
inheriting file descriptors), all of them need to close it or get
terminated before the link count reaches zero and the actual file
content gets deleted.

> That is done by the / some sort of garbage
> collector who marks the file blocks as free once it has detected that
> there is no reference to it anymore.

In case of Unix, it is not a garbage collector (running in the
background) but simple reference counting. The process who causes the
link count of a file to reach zero (either by unlinking the last hard
link on disk if the file is not open, or by closing the last open file
descriptor (or terminating its process) if there are no hard links left)
will immediately get rid of the file on disk.

In case of Project Oberon 2013, the file blocks will remain used until
the system is restarted. Only on restart free blocks get reclaimed.


Regards,


Michael