Black Raven Dragoons

[Zancarius]

After screwing around with putting some addon packages together, I finally found out what culprit is responsible for seemingly "corrupted" entries (although the file integrity themselves seemed okay): IZArc. Evidently, several of the WoWAce addon maintainers (this includes a few FuBar developers) are using this archive software which makes it impossible to read with unzip(1L). 7-zip reads the archives correctly, so this may technically be the fault of unzip. I haven't yet tested zipfile support from within Python to determine if it can extract the files correctly--I might give that a whirl later.

Anyway, I found this bit interesting. As a result, if I find anyone using IZArc, I'm going to force you to run level 1 alts of mine through Gnomer 'til the end of your days. This puts a bit of sand in the cogs of the machinery I was going to use to write an addon manager for us to use internally. So, it appears for now that I'm going to have to use other means of extracting archives on *nix systems.

[Zancarius]

Update: Older versions of Winzip appear to do this, too:

# Why does my Unix UnZip extract flat filenames with backslashes in them instead of a subdirectory tree?

Short answer: because that's how they're stored in the zipfile, and backslashes ('\') are regular filename characters, not directory separators.

Longer answer: older versions of WinZip (and, no doubt, some other clone zippers) stored filenames using backslashes as directory separators in violation of PKWARE's appnote, which specifies that forward slashes ('/') should be used. Newer versions of WinZip correct that bug, so if you created the archive in question, you should upgrade. If someone else did, you should ask them to upgrade.

There is no capability in Unix UnZip to treat backslashes as directory separators (since they're perfectly acceptable filename characters, just like colons, quotes, and pretty much everything other than forward slashes), so if you want to extract the archive as a subdirectory tree without hacking the source code, you'll need to rename the archive entries. See the next item for more information about that.

Info-Zip FAQ.

/sigh

[Zancarius]

Turns out it's not the fault of the application developers are using to compress their archives. I guess all WowAce addons are automatically packaged (probably using a cronjob or some such--I have no idea what their backend looks like, this is just a guess). I initially thought that each addon maintainer was responsible for their own archive. My mistake.

One of their users, probably an administrator or developer, indicated that it may be the fault of the subversion property svn:externals. It struck me as a bit odd, considering the svn:externals attribute is used when checking out files/directories from other repos. But, apparently it's possible to use "\" characters inside the repo URL within svn:externals. I would've never thought that could be done. So, technically, this isn't even the fault of the addon developer or maintainer, considering they were probably using path separators they were familiar with (on Windows, obviously), so they just sort of stuck with what they knew. Then again, it's technically not Subversion's fault, either, because URLs can be specified in a Windows-centric manner using "\" as a separator. In short, I think I'm pretty confident that I've uncovered a rather interesting artifact of behavior that might be worth noting in the future.

Of course, I have a feeling the individual addon maintainers aren't going to give a flying leap. "It works in Windows," they'll probably chime. Ahh well, I have a nifty little Python script that I posted on the 'goon site for future reference which can be used to unzip even malformed archives. Or heck, HG is interested in picking up coding at some point. Maybe this'll give him something to look at.

Edit: *sigh* I'm tired. It isn't actually the URL per se but the local mapping of it. It creates the same general problem, though. I'm sure it works fine on Windows (probably using Tortoise) but craps out when the same local mapping is created according to the repo URL under a *nix environment. Worse, it appears that ext3 doesn't complain about "\" characters in path names. reiserfs does... but Hans is in jail for killing his wife.

[Killemal]

/hurr

[Tirian]

This boy talk devilspeak, I say we exercise him!

[Zancarius]

Elade would agree there, considering she hates computers and thinks they're rather evil.