|
![](/i/fill.gif) |
1) With all the broughaha going on about overwriting files and finding them
lost after a crash, what Linux really needs is a call to say "atomically
swap the contents of file X with the contents of file Y." Would be messy
permissions-wise, I imagine. FAT could use the same sort of thing pretty
easily, altho without journaling you're screwed anyway. With NTFS, you could
just put the write/delete/rename into a single transaction. The old
mainframe I worked on, you could open a file for "output, save", and the
name wouldn't go into the file system until you closed it with "close and
save". If you bombed out, by default the files got closed with "close and
delete", which means all your temp output files got cleaned up and the
previous version of the file was still around. I.e., you could say something
like the UNIX equivalent of "process <xyz >xyz" and it would be quite
happy, and the old xyz would survive if you interrupted it and the new xyz
would survive atomically when it finished.
2) I wonder for how many file writes the process opens the file, writes a
known number of bytes, then closes it, such that the process could inform
the OS at open time how big the file is likely to be, how often it's likely
to be read before being rewritten, and so on. Something like vim could
calculate the resulting file size and avoid having the system pick a place
where it's going to get fragmented. Of course, it could only be a hint, as
anything can guess wrong, get interrupted, or have the file it's copying
change while being copied, for example.
3) I wonder how these defragmenter programs know how many clusters they've
finished. I didn't think the API provided that information. Maybe there's a
new API that's more powerful than the original, for just that reason.
Ah, thinks to ponder while waiting for backups to finish. :-)
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
![](/i/fill.gif) |