When a picture is opened in pix,
and then “deleted” in the file manager,
pix somehow notices, and removes its display of the picture too.
Back in the 90s, we ridiculed movies for acting as if a file opened in a program would just vanish when “deleting” the file. (How could somebody be that clueless about computers, to not understand the difference between in-RAM data, in-video-memory data and a file on disk? That would be like confusing a screen and a computer. Or like thinking streaming is not downloading…)
But it seems somebody took that as an instruction instead of a warning, and actually went, and implemented it! … Because a bug like that doesn’t happen by accident. Somebody actually had to write code to cause it. XD
So, before posting it on TheDailyWTF.com., I thought I’d report it. :)
Steps to reproduce
Well, using a file manager or the like, open a picture in pix, then go back to the file manager, “delete” the file (which overwrites the directory entry, but keeps the inode around until all programs that have it open have exited, and then marks the disk space as free, but of course the actual data stays there, as there is no such thing as “deletion” in computers. Only reading and writing.).
Expected behavior
Since pix has loaded the image to allocated RAM, and parsed it into a data structure, there is zero relation to the file on disk, other than remembering the name for the purpose of writing it after an alteration. So of course, “deleting” the file can not have any effect on pix or the display of the image.
And even if it keeps the file (=inode) open, there is no relation to anything happening to the directory entry. It might even be hard-linked in another directory, and never marked as free at all.
Additional information
I suspect pix registered a file watcher with the kernel, and when notified of the change, also unallocated the picture in memory, to get the same result as in those bad movies.
Distribution
Linux Mint 21.3 Virginia
Package version
3.2.2
Frequency
Always
Bug description
When a picture is opened in pix, and then “deleted” in the file manager, pix somehow notices, and removes its display of the picture too.
Back in the 90s, we ridiculed movies for acting as if a file opened in a program would just vanish when “deleting” the file. (How could somebody be that clueless about computers, to not understand the difference between in-RAM data, in-video-memory data and a file on disk? That would be like confusing a screen and a computer. Or like thinking streaming is not downloading…)
But it seems somebody took that as an instruction instead of a warning, and actually went, and implemented it! … Because a bug like that doesn’t happen by accident. Somebody actually had to write code to cause it. XD
So, before posting it on TheDailyWTF.com., I thought I’d report it. :)
Steps to reproduce
Well, using a file manager or the like, open a picture in pix, then go back to the file manager, “delete” the file (which overwrites the directory entry, but keeps the inode around until all programs that have it open have exited, and then marks the disk space as free, but of course the actual data stays there, as there is no such thing as “deletion” in computers. Only reading and writing.).
Expected behavior
Since pix has loaded the image to allocated RAM, and parsed it into a data structure, there is zero relation to the file on disk, other than remembering the name for the purpose of writing it after an alteration. So of course, “deleting” the file can not have any effect on pix or the display of the image.
And even if it keeps the file (=inode) open, there is no relation to anything happening to the directory entry. It might even be hard-linked in another directory, and never marked as free at all.
Additional information
I suspect pix registered a file watcher with the kernel, and when notified of the change, also unallocated the picture in memory, to get the same result as in those bad movies.