vault.exe mono and OS X

stallent · Post by **stallent** » Mon Jun 21, 2004 11:34 am

I have anxiously been trying to get the vault command line client to run under mono on OS X with each new release of mono. While some progress has been made, I am still having trouble and wondered if there was anyone who has succeeded, or is willing to work together, possibly offlist to get it working.

Here is where I am currently, using Mono Beta 3 (.96).

vault.exe HELP works fine.

Basic commands such as LISTREPOSITORIES work, but begins by emitting an error "Could not load winelib.exe.so". This is a bit strange because I was under the impression that mono uses winelib for winforms stuff, and I assumed the vault command line client would have no references to .net classes that would require winelib under mono. Oh well, LISTREPOSITORIES works fine after that error.

Then when I try anything like LISTFOLDER or LISTUSERS, i get this (after the winelib.exe.so error)

<error>
CRC value in header 1843630660 does not match computed CRC value 1150477165!
</error>
<exception>
System.Exception: CRC value in header 1843630660 does not match computed CRC value 1150477165!
in <0x00358> VaultLib.VaultStreamHeader:ReadFromStream (System.IO.Stream)
in <0x000c0> VaultClientNetLib.VaultConnection:ReadDownloadFileFromStream (System.IO.Stream,System.IO.Stream,string&,long,long&,VaultClientNetLib.VaultConnection/ProgressUpdateFunc)
in <0x002a8> VaultClientNetLib.VaultConnection:GetRepositoryStructure (int,long,long,long&,System.DateTime,System.DateTime&,VaultClientNetLib.ClientService.VaultRepositoryDelta&)

</exception>

Any ideas? It is pretty important to get this working under OS X for us and I am willing to do some legwork to succeed, if anyone has a suggestion.

-stephen

sterwill · Post by **sterwill** » Mon Jun 21, 2004 12:03 pm

I get the "winelib" error too with recent versions of mono, but other things work fine. I think it's harmless.

The exception may be caused by endian problems (we're reading bytes off the network stream and turning them into C# integers). I don't have a Mac OS X machine handy at the moment, but I should soon be able to try to reproduce your problems.

stallent · Post by **stallent** » Mon Jun 21, 2004 12:26 pm

Thanks, Shaw. My first thought was endian-ness, but I thought mono would have taken care of that, or mono would be fairly useless on any big endian machine. I will do a bit of digging on the mono lists and see what I can dig up.

-stephen

sterwill · Post by **sterwill** » Mon Jun 21, 2004 8:27 pm

If it's the problem I think it is, it's not mono's fault, it's ours. We're reading and writing integer values to binary streams, without taking care to order the bytes correctly for the platform.

stallent · Post by **stallent** » Mon Jun 21, 2004 9:04 pm

Cool! Then I can expect a fix soon! Ha! Just kidding.

Thanks, Shaw. Please let me know if there is anything I can do to help. I will gladly even send you an OS X box if it will help get it fixed more quickly!

-stephen

stallent · Post by **stallent** » Tue Jun 29, 2004 3:02 pm

Is this the kind of thing that could get fixed in an upcoming minor release, like a 2.0.4 or something, or will it likely wait until a major release?

Thanks. Just need to know what to expect and be able to tell all of my anxious graphic designers (who are, of course, Mac users).

-stephen

sterwill · Post by **sterwill** » Tue Jun 29, 2004 9:16 pm

It probably won't make it into 2.0.4. OK, it almost certainly won't make it into 2.0.4. It probably will make it into 2.1. Our problem affects more than just the network stream headers we use to encapsulate file data (and the tree structure). It actually affects the way we write our local data files too (the info about the repository that would be stored in a user's home directory). The fix isn't complicated, but since it would affect all of the code that reads and writes those files on all platforms, we wouldn't want to hurry it out in 2.0.4 (scheduled for the next few weeks).