Oolite Bulletins

Simon B wrote:

Hah - didn't know starsoarer was in the wiki ... I'm on to my host service, but now I think about it, I have not heard from them in a while. I see I still own the domain name so we'll see. Probably just a glitch.

It's a long glitch, because I've been checking at least every other day since I reinstalled Oolite (not quite a week) and I still can't get those wonderful ships. Been using Griff's, but I like my updated Aegedian's Specials and X-Ships.

No alternative download site?

CheeseRedux wrote:

There appears to be some errors in the zip: When I try unzipping it I get a lot of 'invalid file name' messages.
Redownloading gave same results.

Windows 'standard' utilities strike again: the zip file is most likely ok, and saved from within a mac. A few system files from macs have got length 0 (plenty of good reasons for that, honest).

M$ unzip utility apparently doesn't like that, and pretends there's an error inside the zip file, instead of carrying on as it should.

If you use a free - standards compliant - unzipping utility like 7-zip you shouldn't get any errors.

Kaks wrote:

CheeseRedux wrote:

There appears to be some errors in the zip: When I try unzipping it I get a lot of 'invalid file name' messages.
Redownloading gave same results.

Windows 'standard' utilities strike again: the zip file is most likely ok, and saved from within a mac. A few system files from macs have got length 0 (plenty of good reasons for that, honest).

M$ unzip utility apparently doesn't like that, and pretends there's an error inside the zip file, instead of carrying on as it should.

If you use a free - standards compliant - unzipping utility like 7-zip you shouldn't get any errors.

Mmmno, not the case. I'm using WinRAR.

From the feedback it gives me it appears that the 'erroneous space' that was in the file name also lurks inside the zip itself.

CheeseRedux wrote:

Mmmno, not the case. I'm using WinRAR.

Provided you tried to unpack v.2.02:

Mmmmyes, the case!

Just downloaded it from Ramirez's site: made on a mac, and the free 7zip utility (better than wirar too imo! ) did unpack it without any problems on this bog standard windows computer, including the mac system files.

It looks like winrar is suffering from the same problem as the windows unpacker... I wonder why... maybe it's piggybacking on the m$ .dll found inside system32?

I don't feel like going down the my zip is better than your zip route.

WinRAR reports 884 errors in the zip, and tries to fix them. As far as I can tell by looking at the folders created, the fix is successful; everything appears in its usual place. The only odd thing is an empty folder called "Trident_Down_v2.0.2" - the files resides in "Trident_Down_v2.0.2_". The appended underscore lead me to the belief that the errors are caused by an errant space in the folder names.

Now, it could be that 7zip just doesn't report the errors, or doesn't recognize them as errors, but unless you are claiming that the errors are caused by the unzip utility I'm using, the fact still remains that there are errors in the zip file.

I am indeed claiming that the errors are invented by the zip utility/operating system you're using!

7zip is intelligent enough to convert the file names for you without freaking out. The file names affected are for the hidden files used by the mac operating system. Since m$ - and apparently winrar - cannot conceive of another os being used, instead of transparently changing the file names affected, they keep telling you 'error, error'.

Using a non-microsoft operating system is not an error, and they shouldn't report it as such. Period.

No idea why winrar created two directories, and filled in the one with the extra underscore. Maybe it's a winrar thing: if it find an error - real or non-m$ ones - it puts stuff in a slightly different directory, to alert you that something is amiss?

With my 'ever-so-lovely' 7zip I can tell there's 2 directories inside the zip file:

Trident_Down_v2.02
_MACOSX

but the trident_down directory name hasn't got any extra/spurious characters. Inside each directory/subdirectory there's a .DS_Store file, inside _MACOSX there's a lot of files starting with '._' nicely tracking the file history of this oxp, which is probably what winrar has been busy 'correcting'.


Allow me to repeat myself once more(4th time lucky?) no matter how much you trust windows/winrar, perfectly valid mac file names are not errors, either zip or otherwise. They should simply not be reported as such. If you feel that strongly about winrar, you should let the winrar developers know, so they can improve on what I've no doubt is a fine windows-only program!

Very well.

To test your claims, I opened up the zip again, this time actually going into the folder structure and instructing WinRAR to extract only the non-mac folder.
Result? The same error messages, though fewer in number (670).
Are you still saying it's a Mac/M$ issue?

Edit: Mac folder, Non-Mac folder issue?

This is the first time that I can remember ever getting such errors unzipping an OXP. A good number of these have contained separate Mac/non-Mac folders, including previous versions of TD.

Even if I were to accept your claim that this is solely caused by the tool I'm using, it is still something that should be fixed. WinRAR is not some obscure tool built by a twelwe-year old and used by him and his two friends, it is one of the more common unzip utilities for Windows.

Just for the record, so we're clear on this:
This is not an issue of me not getting the thing to work; I've identified the problem and verified that the zip utility worked around it. This is me reporting back to the OXP author(s) and general community of various glitches.

The missing ones are 'caused' by the .DS_Store files located under the trident_down directory tree.

Windows itself - I believe microsoft is a pretty substantial company too - refuses to acknowledge mac system files as proper files, and treats them as errors, so no biggie if a slightly smaller company follows on microsoft's footsteps!


I'm sure that once Ramirez removes the mac system files from inside the zip package, as I'm sure he's done in the past, we'll all get a smaller download size, and all your 'errors' will magically disappear.

Trying to unzip just the script folder, which contains no .DS_Store file still gives 34 errors. As far as I'm able to tell without looking at close to 900 error messages, all reported errors relate to faulty file paths, which are then fixed.
The fixed name has a _ at the end, presumably replacing a faulty character.
Combine this with the fact that the original reason why the download was not working was a trailing space in the file name, the logical conclusion is that the same thing is happening with the subfolders.

I just call them as I see them.

Meh, what can I say, it does seem that the foss 7zip is better at dealing with cross platform zip files than the commercial winrar (& the m$ zip utility, though that isn't saying much! ).

Those files are indeed inside that zip file, in the places I mentioned. Nothing I can do if winrar sees them as errors!

In case you're interested in seeing those files for yourself, you can always spend 5 minutes downloading & installing 7zip, unsettling as it would be to see stuff that winrar is telling you can't possibly be there...

In case you're not interested, please do ignore this post!

Cheers,

Kaks

CheeseRedux wrote:

... just the script folder, which contains no .DS_Store file ...

There are plenty of .DS_Store files. I can see them well enough. There are none in the scripts folders.

I am growing weary of this discussion.
I am saying there are potholes in the road.
You are saying it's because I drive a Honda Civic; I should try a SUV instead.

Going into the zip for one last time:
That's a direct C&P of the folder structure leading to the AIs folder in the Mac & Non-Mac folders respectively. Can you see the space? I can.

After removing the trailing space from the two folders within the zip file, I unzip it. No errors reported.
Now can we lay this to rest? Please?

CheeseRedux wrote:

That's a direct C&P of the folder structure leading to the AIs folder in the Mac & Non-Mac folders respectively. Can you see the space? I can.

On the mac it is allowed to include spaces in filenames. Even trailing spaces are allowed, so "myFile" and "myFile " are two different filenames. Of course would it be possible for the zipper to delete those spaces already. But maybe they were intended in the first place and the zip was to be used mac only in the first place. The zipper can not know. So its the job of the unzipper to detect that.

On the mac it is very easy to zip files by using the "archive->compress" menu in the finder. This created archive includes the full mac structure needed to unzip it without any loss of mac specific information. (e.g. the time a file was downloaded or any other general file info) Most window unzippers have no problem with that, but some do. I also had some complaints about my zipped files in the past when using the fully mac compatible method.

Currently I am back to dropZip from the stuffIt package. There you can set the encoding to macBinary (mac compatible) or "never macBinary" (you loose the mac specific information from the resource fork and only keep the text part from the datafork). With zips created that way I never heard complaints from the windows front.

But I agree with Marc: A good unzipper should be aware of different os systems, than realise this is an os issue and fix the problem itself without calling it an error. Most unzippers can.