Oolite Bulletins

I'm making this thread about an issue I keep finding with certain OXPs. When authors who work on the Mac zip up their files, the also zip up several other hidden OS files which break the extraction process on my vista laptop. (It happens on my test XP system too.)

The problem files are a folder _MACOSX and it's contents, .DS_Store and .[name of the oxp].oxp. These are clearly system files for OS X. When I use any any zipping program (including 7zip which handles everything) to auto-extract the files, it crashes saying that it encounters multiple zero byte files and generates a junk folder with a bit of random junk files. When I open the zip and manually select the oxp folder and extract that, it works fine.

It took me a while to figure out what what happening, and almost put me off oxps in the process. I shudder to think what a newby would thought when encounter the problem. Please don't think I'm picking on the Mac either, I'm sure stuff sneeaks in on PC and Linux zips too. So please could you do a bit 'hoovering' of zip files before uploading.

I have had this problem to, on about 50% of OXPs there are 0 byte files with the same name as a folder in the OXP.

KZ9999 wrote:

The problem files are a folder _MACOSX and it's contents, .DS_Store and .[name of the oxp].oxp. These are clearly system files for OS X. When I use any any zipping program (including 7zip which handles everything) to auto-extract the files, it crashes saying that it encounters multiple zero byte files and generates a junk folder with a bit of random junk files. When I open the zip and manually select the oxp folder and extract that, it works fine.

With 7zip I don't get this problem, however I do select the file with the mouse and then use 7zip to extract them via the context menu. Maybe it's depending upon the way it's called to extract the file?

The Vista internal zip system did fail to unpack some OXPs for me...luckily I knew about 7zip before. Maybe 7zip should be linked on the Wiki for oxps

Screet

Speaking for the Mac OSX I see only two different ways to create zip files. I have used both in the past and there were always people that claimed one is better and others claiming the other is better. So I don't really know and choose the easiest way.

1- Select a file a file and choose "Make archive" from the mac finder menu. This creates an zip file with all the extras in it so OSX can recreate a complete mac file from it.

2- Use the drop-zipper that is also installed with OSX. With this drop-zipper one can select in the preferences to use always or never mac-binary. Mac-binary files also preserve all the mac attributes, but most window zippers will have serious problems with it. When selecting never mac-binary you get cross platform files but mac files loose some attributes. I have been a remote system operator for a mac bulletin board around 1990 and know this mac-binary thing was always a problematic issue for users. And as it is hidden in the preferences a user could miss it. (specially most users never look at their preferences regularly) And when they put this off by default, some mac only files will be crippled for use on the mac. The drop-zipper also includes a "smart" option, but that probably only recognises text files but will see oxp as a mac file.

OSX does not allow to look inside the zip-files with normal tools so it is always difficult to see what is inside. And when unzipping all those special files are removed again and not seen my mac users.

I now used an old classic zipper from OS-7 to look inside. I noticed that method 1 adds all the extra files and folders you mention. Method 2 with option mac-binary off only adds one extra file and that is a zero byte icon. So method 2 will avoid your troubles. From my experience I am just afraid that most mac uploaders will have problems with setting the right preferences and will create mac-binary files inside the zip. And there are probably window unzippers that can cope with this, I think most won't.

I asked this question twice in the past and sometimes uploaded files in both versions. I always got biassed reactions from the window community to what version was better. Looking inside the file I think I 'll use method 2 in the future but, for the broad majority I think method 1 is better and we need better explanation on the wiki download page what type of unzippers to use.

As Screet says, 7zip (a free, open source unzipper) hasn't got any problems with 0 length files.

I think that the standard windows unzipper would still have a problem with the 0 bytes icon from method 2.

Unfortunately when m$ added their own zip extractor to their own OS, they didn't seem to think about possible cross platform issues...

Standard m$ tactics, as far as I can tell...

Kaks wrote:

As Screet says, 7zip (a free, open source unzipper) hasn't got any problems with 0 length files.
I think that the standard windows unzipper would still have a problem with the 0 bytes icon from method 2.

Yupp, the internal unzipper has this problem, but hey - there are hundreds of unzipper out there. 7zip and a lot other progs don't have this problem (and are faster than the internal one).

And if you have downloaded the package - simply remove the Mac-specific part if you don't need it. So I think it is not a big problem and Mac-users don't have to worry about it.

I use Info-ZIP unzip. No problems, but __MACOSX etc. are extracted by default. Now, if people wouldn't put spaces in their file & directory names, we could do without that -print0/-0… mutter mutter grumble mutter grumble grumble mutter mutter whinge

OFFTOPIC WARNING!!!!

@Kaks

Kaks wrote:

Unfortunately when m$ added their own zip extractor to their own OS, they didn't seem to think about possible cross platform issues...

Standard m$ tactics, as far as I can tell...

Actually MS did think about cross-platform issues. Unfortunately, the DoJ Monopoly decision means they run into a few problems when they want to provide a lot of nicer functions...

Svengali wrote:

Yupp, the internal unzipper has this problem, but hey - there are hundreds of unzipper out there.

↑↑↑↑↑↑ THAT is why MS can't expand the internal compression program's features to handle things like 0-byte files from cross-platform archives. There is already third-party product competing in that space.

Cmd. Cheyd wrote:

Svengali wrote:

Yupp, the internal unzipper has this problem, but hey - there are hundreds of unzipper out there.

↑↑↑↑↑↑ THAT is why MS can't expand the internal compression program's features to handle things like 0-byte files from cross-platform archives. There is already third-party product competing in that space.

I believe you are mistaken.

Firstly, I think the overall description is wrong. But more specifically, fixing a crashing bug is not adding a feature in the first place.

I searched for some other easy usable Mac zippers. I found YemuZip. Very easy to use and explicitly mend to create files that can be used on windows. Looking inside the archive it also added the 0 byte icon file. So back to my better known stuffIt zipper that created an identical file.

I did notice that I could delete the 0 byte file with my old OS-7 zipper. Modern free versions of the zip programs don't seem to include these options anymore.

Ahruman wrote:

Cmd. Cheyd wrote:

Svengali wrote:

Yupp, the internal unzipper has this problem, but hey - there are hundreds of unzipper out there.

↑↑↑↑↑↑ THAT is why MS can't expand the internal compression program's features to handle things like 0-byte files from cross-platform archives. There is already third-party product competing in that space.

I believe you are mistaken.
Firstly, I think the overall description is wrong. But more specifically, fixing a crashing bug is not adding a feature in the first place.

Hmmm - I think you are right Ahruman. Why should this be a problem for M$ to fix a problem in one of their modules? This should be their job, but they simply don't do it. So (as XP-user) I'd say choose another one .-) Personally I'm trying to replace most of the internal stuff with other tools (and disable or delete the internal ones). This has worked for years now without all these problems. But M$ doesn't make it easy and sometimes it needs some registry tweaks to get a good result, but it is possible.

It isn't a a crashing bug. I noticed the behavior when I first started with Oolite and downloaded a bunch of OXPs. The program throws an error / information box because there is already a file with that name in the directory. You can either skip the file, cancel, or ... something. I forget...

Anyways, they can't program in the intelligence because it expands the core OS's feature set into an area where competitive products already exist. To do so would run them afoul of "leveraging their monopoly standing in the OS market to gain an unfair advantage within the [compression/decompression] market space".

Cmd. Cheyd wrote:

It isn't a a crashing bug.

Yes, but it's nasty.

Cmd. Cheyd wrote:

Anyways, they can't program in the intelligence because it expands the core OS's feature set into an area where competitive products already exist. To do so would run them afoul of "leveraging their monopoly standing in the OS market to gain an unfair advantage within the [compression/decompression] market space".

No, they are excluding themselves. Reliability looks different and if they are not able to fix such a small problem, then I'd say they don't do their jobs. M$ is earning money for a product that does not work (in this case). I'm working in a business where a lot of different platforms are used - so they will lose customers if their product is not working. Is this a good strategy?

Don't get me wrong - I'm pleased with XP Pro, but my OS is totally customized. And for me it is absolutely no problem to use another zipper, but think about unexperienced users - they will run into trouble.

Edit: Typos

Svengali wrote:

Don't get me wrong - I'm pleased with XP Pro, but me OS is totally cusomized. And for me it is absolutely no problem to use another zipper, but think about unexperienced users - they will run into trouble.

The way M$ works is induscutable anyway. With Vista SP1 they introduced incompatibilities to some of their software (e.g. Outlook) which is bundles with quite new PocketPC devices. Microsofts answer to these bugs: "The software has known errors but is out of warranty. We suggest you buy an up-to-date version of the software".

I'm sure that anyone who suffers from such a behaviour of disabling old software to force users to buy their new one results in dissatisfaction which leads to switching to other applications / operating systems.

Screet

I now know how those zero byte icons enter the mac files. In the file-info window you can always add custom icons to folders. e.g. by selecting and copying it from one folder info and paste it in the other.
This action adds an icon to the folder. With osx this is a hidden file inside the folder. For icons the data-fork is empty and the resource fork contains the picture. Resource forks are something unknown to windows. When you save it as mac compatible zip, it puts all the resource forks in the special mac folder and puts the empty data-fork as empty file in the normal area.

My oxp's never contained icons but I noticed that even when you remove the icon in the info window, the osx only removes the picture from the icon file but does not delete the icon file itself. It leaves a small hidden file back. 0 byte data fork and 128 byte resource fork.

For the mac compatible version there is no other solution for the zipper, but when selecting the window compatible mode it is a mac zipper bug to also add those zero byte files.

At least I know see why some of my oxp files did contain an empty icon file.