| |||||||||||||
Many more words on volatile rangesMany more words on volatile rangesPosted Nov 8, 2012 7:47 UTC (Thu) by dlang (✭ supporter ✭, #313)In reply to: Many more words on volatile ranges by foom Parent article: Many more words on volatile ranges
> But without taking extra preventative measures, the ability to ever once *have* *had* permission to modify a file might then result in the ability to modify the file (by zeroing out some blocks) any arbitrary time in the future.
remember that permission checks are only made when the file is opened, so even without this you could hold the filehandle open and erase blocks at any time.
Yes, this can now happen even after the program has exited (more below)
> But these new files aren't sparse immediately; volatile data does use up actual space, until it gets dropped on the floor. That's a brand new type of thing.
you can do one of two things by default (and either one is defensible)
1. show the size as it currently occupies disk space
2. show the size as if the holes had been reclaimed by the filesystem
I would probably do #1, because with sparse files, you already have a situation where the file size on disk can change significantly, so this is not that different.
to cover the rest of the first problem, and the corner cases of the second problem, there will need to be a utility to report on what's been tagged as being volatile, but that tool will probably just be needed for odd, corner cases. The existing options for dealing with sparse files should cover the 'normal' needs
(Log in to post comments)
|
|||||||||||||