Which you should take as a "maybe I have misunderstood the issue".
This is not an edit list, or the ability to undo operations. The problem is you have an existing file ("foo.png" or whatever):
oooooooooo
then you make a new file with this data in memory:
nnnnn
This could be something like you opened the original foo.png file and made a change that results in the file shrinking, or it could be some completely unrelated data. Now you save this as foo.png and the editing program assumes opening a file for writing will erase the old data and writes out the new data. The end result is you have this file:
nnnnnooooo
e.g. the tail of the old file is still present in the file data. It turns out it's possible to recover the pixel data from those tail bytes, in spite of losing the compression state.
Now the assumption that writing over an existing file will truncate/erase the original file is reasonable. That's the default behavior of most file IO APIs. I don't know what the windows app is doing, but the original android bug was an API that takes a mode string copied from posix's fopen, in which "w" means "open for writing, and erase any existing file", but then later on made an undocumented change that made opening a file with "w" no longer erase existing files.
Which you should take as a "maybe I have misunderstood the issue".
This is not an edit list, or the ability to undo operations. The problem is you have an existing file ("foo.png" or whatever):
then you make a new file with this data in memory: This could be something like you opened the original foo.png file and made a change that results in the file shrinking, or it could be some completely unrelated data. Now you save this as foo.png and the editing program assumes opening a file for writing will erase the old data and writes out the new data. The end result is you have this file: e.g. the tail of the old file is still present in the file data. It turns out it's possible to recover the pixel data from those tail bytes, in spite of losing the compression state.Now the assumption that writing over an existing file will truncate/erase the original file is reasonable. That's the default behavior of most file IO APIs. I don't know what the windows app is doing, but the original android bug was an API that takes a mode string copied from posix's fopen, in which "w" means "open for writing, and erase any existing file", but then later on made an undocumented change that made opening a file with "w" no longer erase existing files.