Exercises for the interested reader
Posted Nov 25, 2010 16:07 UTC (Thu) by lacos
Parent article: Ghosts of Unix past, part 4: High-maintenance designs
1. Identify a design element in the IP protocol suite which could be described as "high maintenance" or as having "unintended consequences".
and TCP urgent data
come to my mind.
3. Research and enumerate uses of "hard links" which are not adequately served by using symbolic links instead. Suggest technologies that might effectively replace these other uses.
Some programs do this:
- Create a file.
- Work with the file.
- If the work completes, close the file, leave the reference (the name) in the fs.
- If the work is interrupted or fails, close the file and remove the reference (in some order).
It is sometimes useful to add an independent hard link to the file during step 2, so it can be salvaged when the program removes it in step 4. Example: downloading a big file with your browser, then continuing it with wget.
The non-plus-ultra of hard-linking is flink()
. Among other things, it should allow for a very useful operation: make a file reappear instantenously in the filesystem. Consider the practice of some utilities:
- Create a temporary file.
- Remove its name immediately, but keep it open by file descriptor, file description, and inode.
- If the work completes, close the file. With the last reference going away, the space occupied by the file is released.
- If the program crashes, or eg. a SIGKILL is delivered to it, the previous step happens automatically. Nothing left around to clean up later.
flink() extends this workflow for files that you want to keep in the end! Just replace the third step in the previous list: if the work completes, flink() the file back into the filesystem, then close it. It's like a lightweight "commit transaction" statement, with automatic rollback on failure.
to post comments)