Should scene.org still rewrite .zip files?
category: general [glöplog]
For as long as I've been using it, scene.org has been rewriting .zip files uploaded to add a small ASCII art logo and some text, and put that as the zip comment. I assume that this is a holdover from (or perhaps an homage to) BBSes, which used to do this as a form of advertising (you can still see this in e.g. some torrents, I believe).
However, scene.org doesn't really need that advertising anymore; BBSes are no more, and pretty much everyone who would ever want to upload a demo somewhere these days will know about it. And as the world has progressed, we have seen a shift towards caring much more about maintaining the integrity of data (witness e.g. HTTPS everywhere, or subresource integrity for JavaScript). As an author, I've always found it a bit icky that scene.org goes in and modifies my release, if only slightly (I believe it doesn't e.g. repack, at least not in the common case).
Having a text file in there is also practically annoying; it breaks deduplication (a question such as “is scene.org's version the same as the compo version or the final version?” now requires much more logic to figure out; you can't just compare files anymore), it breaks heuristics to figure out whether to ignore or keep a top-level subdirectory when unpacking, and it feels very half-baked: It only works for .zip files, not .rar, .tar.gz, .mp3 (which can also carry comments), .mp4 or really whatever.
Perhaps, as scene.org nears its 30th birthday, we can decide that this rewrite no longer is expedient, and stop doing it for new uploads? (I wouldn't want to go in and remove them from old files; two wrongs don't make a right.)
However, scene.org doesn't really need that advertising anymore; BBSes are no more, and pretty much everyone who would ever want to upload a demo somewhere these days will know about it. And as the world has progressed, we have seen a shift towards caring much more about maintaining the integrity of data (witness e.g. HTTPS everywhere, or subresource integrity for JavaScript). As an author, I've always found it a bit icky that scene.org goes in and modifies my release, if only slightly (I believe it doesn't e.g. repack, at least not in the common case).
Having a text file in there is also practically annoying; it breaks deduplication (a question such as “is scene.org's version the same as the compo version or the final version?” now requires much more logic to figure out; you can't just compare files anymore), it breaks heuristics to figure out whether to ignore or keep a top-level subdirectory when unpacking, and it feels very half-baked: It only works for .zip files, not .rar, .tar.gz, .mp3 (which can also carry comments), .mp4 or really whatever.
Perhaps, as scene.org nears its 30th birthday, we can decide that this rewrite no longer is expedient, and stop doing it for new uploads? (I wouldn't want to go in and remove them from old files; two wrongs don't make a right.)
Quote:
Should scene.org still rewrite .zip files?
No.
For all the reasons you mentioned.
To be fair, most of the files I've uploaded in recent years did not get nfo's inserted, or at least I did not notice that happening. But making it a policy not to modify archives any more than strictly necessary seems the logical way to move forward nonetheless.
just upload .7z or something?
Yeah, the real WTF is using Zip or RAR in 2026.
That winrar license gotta pay off :)
havoc: You're right in that it seems to be inconsistent. E.g., looking at .zip files in /parties/2026, fioniadata2026/ and amiparty35/ have no comments but rsync26/ and gerp26/ (and most others) have. mountainbytes26/ has in some files. I assume that it depends on the upload method somehow (perhaps some of these are just moved directly into the tree by scene.org admins, bypassing the usual scripts?).
I’m totally fine with Scene.org adding their own info to my archives. I’m already grateful they store my stuff, and hundreds of terabytes of other junk for free :)
And yeah, BBS traditions are cool. That’s the demoscene. Next you’ll say ASCII isn’t relevant anymore.
As for ZIP… it’s a standard. You can unpack it on pretty much any computer without installing extra software. I don’t even have 7zip or RAR, not sure why I’d need them. Are you worried about compression ratio? For what? Downloading files faster? Are you on dial-up? ;)
ZIP is like JPEG, MP3, TXT. We don’t release gfx in WebP or music in WebA and include a description in DOCX, right?
And yeah, BBS traditions are cool. That’s the demoscene. Next you’ll say ASCII isn’t relevant anymore.
As for ZIP… it’s a standard. You can unpack it on pretty much any computer without installing extra software. I don’t even have 7zip or RAR, not sure why I’d need them. Are you worried about compression ratio? For what? Downloading files faster? Are you on dial-up? ;)
ZIP is like JPEG, MP3, TXT. We don’t release gfx in WebP or music in WebA and include a description in DOCX, right?
Yes.
For all the reasons you mentioned.
For all the reasons you mentioned.
What manx and most of the others said. No.
Furthermore, in the remote case that a production magically gets whitelisted (which is extremely rare, but it seems it did happen in the past), it is likely beneficial if the original archive isn't being modified/manipulated.
Furthermore, in the remote case that a production magically gets whitelisted (which is extremely rare, but it seems it did happen in the past), it is likely beneficial if the original archive isn't being modified/manipulated.
Quote:
As for ZIP… it’s a standard. You can unpack it on pretty much any computer without installing extra software.
It's certainly a standard, yes.
But if going for widespread support out-of-the-box, it's hard to beat tar, which has been standard on POSIX systems since before ZIP existed and nowadays is bundled even with Windows in the form of bsdtar. In addition to the pure archiving functionality, all major implementations including bsdtar also support compression using a variety of algorithms. Unlike ZIP it has the courtesy to properly preserve Unix file attributes as well.
I think the only thing ZIP has going for it really is habit and familiarity, principle of least astonishment kind of thing. But for example 7z is already 25 years old by now, has a lot of traction in the wild, and is just as open a format as ZIP while simply being better in general.
Zip on Amiga files needs to end, the Amiga specific file flags to files are not saved properly then. LHA or LZX.
Tbh I would love it to see my prod with a bunch of BBS and repository text files added.
Quote:
Unlike ZIP it has the courtesy to properly preserve Unix file attributes as well.
Zip file entries have a 4-byte field that are used to (among others) store UNIX file attributes, assuming the packer cares to set them. (The standard “zip” tool on Linux does.)
Quote:
Zip on Amiga files needs to end, the Amiga specific file flags to files are not saved properly then
Fix the Amiga (un)zip program then?
Quote:
Tbh I would love it to see my prod with a bunch of BBS and repository text files added.
This. In a world where everything organic is being commoditized, let’s try to preserve what once mattered.
