3 ms·

Why is this so hard? Why can't we just specify that a particular file needs to be actually deleteable and that we don't want the system (at any level) to leak c

Why is this so hard? Why can't we just specify that a particular file needs to be actually deleteable and that we don't want the system (at any level) to leak copies of any of the data in that file? There is no technical reason this is not possible, it is just a convention that has caused problems since the dawn of computing. There is no point in making a file system that supports that filesystem would not be able to specify deleteabiliy to the hardware. There is no point in making hardware that supports this because there is no file system that exists that would have anything to tell the hardware. This situation exists simply because of inertia. Sure there would be performance implications, but who would care? You might just want to store a key for some full performance encrypted data that you would like to be able to actually remove access to. Sometimes performance is not the most important thing to optimize for.

wtallis 4y ago
> There is no technical reason this is not possible, it is just a convention that has caused problems since the dawn of computing. Technical reasons are all over the place, because the only "convention" you could possibly be referring to is the practice of having layers of abstraction for compatibility purposes. If you want to re-design your entire storage stack to accommodate every new technology, then it's trivial to ensure deleteability in each from-scratch re-design. But as soon as you want to use flash memory to build a drop-in replacement for hard drives, it gets quite difficult to retain this property without making huge sacrifices to more desirable properties.
- upofadown 4y ago
  It would be possible to add this particular bit of information without changing anything that affects compatibility. The only difference would be that some files would actually be deleted when a delete operation was applied. It is a separate information channel that can be added on top. This has nothing in particular to do with flash vs spinning rust. A copy on write file system for example generates tons of information leaking copies all the time, but could trivially be be changed so that some files did not leak in that way. This is truly one of those issues that exists simply because no one can be bothered to fix it.

wtallis 4y ago

> There is no technical reason this is not possible, it is just a convention that has caused problems since the dawn of computing. Technical reasons are all over the place, because the only "convention" you could possibly be referring to is the practice of having layers of abstraction for compatibility purposes. If you want to re-design your entire storage stack to accommodate every new technology, then it's trivial to ensure deleteability in each from-scratch re-design. But as soon as you want to use flash memory to build a drop-in replacement for hard drives, it gets quite difficult to retain this property without making huge sacrifices to more desirable properties.

upofadown 4y ago
It would be possible to add this particular bit of information without changing anything that affects compatibility. The only difference would be that some files would actually be deleted when a delete operation was applied. It is a separate information channel that can be added on top. This has nothing in particular to do with flash vs spinning rust. A copy on write file system for example generates tons of information leaking copies all the time, but could trivially be be changed so that some files did not leak in that way. This is truly one of those issues that exists simply because no one can be bothered to fix it.