How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
This is NOT a file format that corrupts itself. This is a file reader that corrupts files. There's a big difference. Nothing about the format itself causes or requires corruption. A better tagline would be "decayfmt is a social contract enforced by pinky promise".
Tie::Hash::Cannabinol is a completely useless demonstration of how to use Tie::StdHash to
pervert the behaviour of Perl hashes. Once a hash has been tied to Tie::Hash::Cannabinol,
there is a 25% chance that it will forget anything that you tell it immediately and a
further 25% chance that it won't be able to retrieve any information you ask it for. Any
information that it does return will be pulled at random from its keys.
Oh, and the return value from exists isn't to be trusted either :)
From what I remember, MS Paint do something similar when you would save the image as a jpeg. It would apply the algorithm each save and the image would degrade a bit each time. It was super fun.
Not quite same thing though. JPEG re-save loss comes from re-encoding, not some deliberate "decay" gimmick. Calling MS Paint's lossy compression "fun degrading" kind of glosses over that it was just a bug people misread as a feature.
Reader side's simple: don't rely on it as backup. We had a customer store configs in a format nobody versioned properly, lost history in an outage. Decay by design just makes that failure mode explicit instead of accidental.
A virus I wrote in the '90s did just that - every time you opened a file, it damaged a small random part of it. My plan was also to randomly change the digits of numbers when printed on paper. I wrote this because a friend of mine managed to steal my source code during my naive XOR encryption. The "encrypted" files had a bunch of zeroes, and he saw my password. My virus worked. First, it damaged his working copy; then he tried to copy the backup, but in doing so, he damaged it, too, even though he claimed his backup diskette was write-protected. The virus didn't spread because I knew how evil it could be - just as evil as MS-DOS, which would run a hidden .COM file without thinking twice. So many fast typists like me were often mistyping "DIR" as "DUR", so I just put my virus in a hidden DUR.COM, copied it into the empty allocated space of COMMAND.COM (less than 200 bytes), and printed out "Bad command or file name". So, the theft was avenged!
P.S. I didn't specify, I didn't have my own computer, only used computers at school and my friend's personal computers, leaving "encrypted" files in case I forgot to bring my diskette. So, after he stole my code and some personal files, her never left me alone on his computer, but he never thought I would infect his computer so easily right in front of his eyes without him realizing it!
A better analogy would be if every time you played the video file, the mechanism hallucinated a little, bringing in your current feelings as input to change the emotional undertones (and possibly characters and events) depicted in the video.
Whose feelings, though? Mine or the last person who watched it? If it's cumulative you'd get some weird averaged-out emotional residue from every viewer, not a personalized hallucination.
Seems like there is no mechanism to allow non-corrupting reads from authorized processes? Begs the question then of what the point of this is. Pure novelty, or truly something that could be used in practice?
A company I was at had a disk array that would do something like this. It wasn't a documented feature mind you. During writes, it would randomly zero out data within a file. So at least it didn't get progressively worse, but it was a bear to isolate. These were large media files so a quick look at the head/middle/tail could easily miss the problem areas.
Ran something like this on a research archive years back, "self-healing" backups that XOR'd bit flips into checksums on read. Nightmare debugging silent corruption from the reader itself, not disk rot. Gotcha: your fsync timing matters more than the algorithm.
