Ask Reuben – July 23, 2025

Extracting zip Quirk

Why when I extract some .zip files from Four Js do they go into one folder with the file name as the folder name, and other .zip files extract into a folder with a name that is not the file name?

One thing I like our products to be is to be consistent with one another.  Hopefully you will find that at the simplest examples with our command line arguments, -h = help and -V = version, being consistent across our product range. We don’t want you, and we don’t want to do it ourselves, is to have to remember to use different arguments with different products.

One area of potential inconsistency was recently highlighted with our products that are delivered as .zip files.  The comment was that if our .zip file was foo.zip, then for some products this would be extracted into a folder named foo, whilst for other products it would be extracted into a folder with a different name.  This was occurring with the two different .zip files for the GBC Runtime and GBC Project packages.  The runtime would extract into a folder fjs-gbc-X.YY.ZZ-buildYYMMDDHHMMSS-runtime, whilst the project would extract into a folder gbc-X.YY.ZZ. (where X.YY.ZZ is the version and YYYYMMDDHHMMSS is Year, Month, Day, Hour, Minute, Second ).

It puzzled us initially, but what we eventually traced it too was that it was not something our packaging team was doing explicitly, but it was a feature of the software being used to unzip the .zip file.  The (Un)Archive Utility  (or unar from the command line) which is the default tool on OSX had the following in the list of arguments …

-force-directory (-d)                   Always create a containing directory for the contents of the unpacked archive. By default, a directory is created if there is more than one top-level file or folder.

… that last sentence was the key to unlocking what was going on.

If our .zip file contained only one directory, as our GBC product .zip files did with a directory named gbc-X.YY.ZZ, then when this was extracted no containing directory was created.  If our .zip file contained many directories, as our GBC runtime zip file did (js, license, release, resources, themes) then when this was extracted, a containing directory was created using the name of the .zip file (less the .zip suffix), that is a containing directory named fjs-gbc-X.YY.ZZ-buildYYMMDDHHMMSS-runtime was created and the contents of the zip were placed in this directory.

So it was not something we were doing explicitly, but something that was the default behaviour of the software used to extract the .zip file.