Packager directory structure issue

[cosmeg]

I see this with ShieldsUp, on a Macintosh. There seems to be a backslash inserted into the directory names instead of creating a "Libs" directory.

This happens with the default "Archive Utility" as well as the command line zip program.

lava:shieldsup john$ unzip ShieldsUp-3.0.9.44-beta.zip 
Archive:  ShieldsUp-3.0.9.44-beta.zip
   creating: ShieldsUp/
   creating: ShieldsUp/Locales/
  inflating: ShieldsUp/Locales/ruRU.lua  
   creating: ShieldsUp/Libs\LibSink-2.0/
  inflating: ShieldsUp/Libs\LibSink-2.0/lib.xml  
  inflating: ShieldsUp/Libs\LibSink-2.0/LibSink-2.0.lua  
  inflating: ShieldsUp/README.TXT    
   creating: ShieldsUp/Libs\LibSharedMedia-3.0/
  inflating: ShieldsUp/Libs\LibSharedMedia-3.0/lib.xml  
  inflating: ShieldsUp/Libs\LibSharedMedia-3.0/LibSharedMedia-3.0.lua  
  inflating: ShieldsUp/Options.lua   
   creating: ShieldsUp/Libs\LibStub/
  inflating: ShieldsUp/Libs\LibStub/LibStub.toc  
 extracting: ShieldsUp/Libs\LibStub/.pkgmeta  
  inflating: ShieldsUp/Libs\LibStub/LibStub.lua  
   creating: ShieldsUp/Libs\CallbackHandler-1.0/
  inflating: ShieldsUp/Libs\CallbackHandler-1.0/CallbackHandler-1.0.xml  
  inflating: ShieldsUp/Libs\CallbackHandler-1.0/CallbackHandler-1.0.lua  
  inflating: ShieldsUp/Core.lua      
  inflating: ShieldsUp/ShieldsUp.toc  
  inflating: ShieldsUp/Widgets.lua   
lava:shieldsup john$ ls -F ShieldsUp
Core.lua			Locales/
Libs\CallbackHandler-1.0/	Options.lua
Libs\LibSharedMedia-3.0/	README.TXT
Libs\LibSink-2.0/		ShieldsUp.toc
Libs\LibStub/			Widgets.lua

I hope the directory structure is clear.

Version info, for reference. (And yes this program hasn't changed since 2005.)

lava:shieldsup john$ unzip -v
UnZip 5.52 of 28 February 2005, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.0.1 (Apple Inc. build 5465) for Unix on Sep 23 2007.

UnZip special compilation options:
	COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
	SET_DIR_ATTRIB
	TIMESTAMP
	USE_EF_UT_TIME
	USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
	USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
	VMS_TEXT_CONV
	[decryption, version 2.9 of 05 May 2000]

UnZip and ZipInfo environment options:
           UNZIP:  [none]
        UNZIPOPT:  [none]
         ZIPINFO:  [none]
      ZIPINFOOPT:  [none]

[Phanx]

I don't use a Mac, but is there really no ZIP decompression software you can use that's not 14 years old? My roommate does use a Mac, and uses several of my addons, including ShieldsUp, without any issues like the one you're having.

[cosmeg]

Well as far as I know info-zip is the definitive zip software for unix based platforms. I know it sounds funny but that really is the latest version of this software (the zip format hasn't changed apparently).

If the wowinterface packager is based on linux it probably uses this same software. But I can't be sure.

I also tried Stuffit Expander, v. 11.0.1 11/16/2006.
The aforementioned Archive Utility is v. 10.5.1 12/16/2008, the most current version. This is what is used when you double-click the zip file and what most mac users will use.

I do admit this is strange if it works for some people with a mac but not others. I just tried it with ShieldsUp as my only addon and it wouldn't work (didn't load libs) until I fixed the directory structure.

Hope this helps.

[Shirik]

Technically this is legal. According to the specification, forward slashes and backslashes have the same effect in path names, and can be mixed. If your archiver is not properly handling this case, then it is wrong.

That being said, it would probably be preferable to normalize it. However I do know that the system was developed by someone with a Mac, so I do find it very strange that you are having this issue and he did not.

EDIT: Actually, it appears I was wrong. Backslashes are forbidden. I must have been thinking of a different specification.

[cosmeg]

Originally Posted by Shirik EDIT: Actually, it appears I was wrong. Backslashes are forbidden. I must have been thinking of a different specification.

Bah you're too quick Here's what I was going to post, hope it's useful for someone.

Originally Posted by http://www.info-zip.org/FAQ.html#backslashes 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.

Originally Posted by http://www.pkware.com/documents/casestudies/APPNOTE.TXT All slashes should be forward slashes '/' as opposed to backwards slashes '\' for compatibility with Amiga and UNIX file systems etc.

I'd just like to make it clear that I'm not seeing this problem with all addon zip files, just ShieldsUp as far as I know.

[Slakah]

I've got a similar problem with ReallyFlyable and xarchiver 0.5.2 on Fedora Core 10.