User: Password:
|
|
Subscribe / Log in / New account

Ghosts of Unix past, part 4: High-maintenance designs

Ghosts of Unix past, part 4: High-maintenance designs

Posted Dec 17, 2010 1:23 UTC (Fri) by rich0 (guest, #55509)
Parent article: Ghosts of Unix past, part 4: High-maintenance designs

The article mentions in passing that it is safer to write changes to a new file and rename it than to overwrite a file in place. This in itself is actually an example of a bad design - similar to the recent fiasco over app designers being told to fsync their changes.

The ideal design would be for applications to tell the OS what they want to do, and for the OS to do it. In this case, the application WANTS to atomically modify the contents of a file, but since the OS provides no capability for atomic updates instead the application PRETENDS that it wants to create a new file, rename it, and unlink the old one.

The solution in this case is transaction support within the filesystem. Then if you have a copy-on-write filesystem or whatever you're not forcing the system to rewrite the entire contents of a file to change a few bytes in the middle safely.


(Log in to post comments)

Ghosts of Unix past, part 4: High-maintenance designs

Posted Dec 17, 2010 3:38 UTC (Fri) by neilbrown (subscriber, #359) [Link]

I agree that it is best to be able to tell the OS exactly what you want to do, though sometimes that can be tricky.

In the case of modifying a file, if it really is just a few bytes in the middle that you want to change, then getting a lock, writing those bytes, and unlocking is probably best.

However in many cases you want to change N bytes in the middle of the file to M other bytes. This either requires non-linear transformations on the file, or the remainder of the file to be re-written. The former would hardly ever by used and so would be buggy. The later is very little less effort than re-writing the entire file.

So I still think that 'write a new file and replace the old' is a good model to follow.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds