Small binaries (*.ctx, *.frx) get corrupted
Moderator: SourceGear
Small binaries (*.ctx, *.frx) get corrupted
Upon import of certain vb-resource files (*.ctx, *.frx) the result in Vault is an empty file. This happens when the binary in question consists of nothing but binary zeroes. In the underlying cases, the binaries were each 4 bytes of zero, resulting in empty files in Vault. We were able to check in the original binaries in Vault without any problems. It seems that not Vault, but the import tool is the problem here. It seems worth the while to point out in the documentation that a recursive show diff after the import is vital.
We'll investigate this scenario.
In the meantime, can you upload / send your import log file. It should be located in the Vault Import Tool's directory. Also the corresponding
Vault Server Log.
Finally, can you tell me the version of ssapi.dll is installed on the system where you ran the import tool? Here's how to find the version number:
http://support.sourcegear.com/viewtopic.php?t=1510
In the meantime, can you upload / send your import log file. It should be located in the Vault Import Tool's directory. Also the corresponding
Vault Server Log.
Finally, can you tell me the version of ssapi.dll is installed on the system where you ran the import tool? Here's how to find the version number:
http://support.sourcegear.com/viewtopic.php?t=1510
Jeff Clausius
SourceGear
SourceGear
instead of snipping through the logfiles, I considered it better to send them to you via private mail - however either my mailfolder or yours seems to be exceeding limits. The zipped logs are 970KB. Perhaps you can tell me some other means of uploading them (anon ftp, e-Mail)?
As for commenting the logs: the following files were corrupted after the import, they all consisted of 4 binary zeroes, after import they were empty:
$/exe32/TstEdge/ucCmp.ctx
$/exe32/konfedge/frmadd.frx
$/exe32/knedge/Code.ctx
$/exe32/KfDialog/ucEnv.ctx
In VSS they are all marked as binary, but also with auto-detect encoding - seems to have been the default for these VB-files.
Note that the various errors "item with the same name or object id already exists" were caused by a previous abort of a VSS_import. Part of the folder structure had already been created before any files were imported. The problem with the small binaries also occurs in a brandnew DB. This is merely the newest import of 7 test-runs. Also the missing revisions listed at the end of the import log are mainly files that were marked with "do not keep older versions", the rest of them were VSS-corrupted (and VSS-fixed int he way VSS fixes these inconsistencies) at some earlier point in time in the day-to-day usage of VSS. These corruptions are, by the way, the main reason that we are evaluating alternatives to VSS.
On the machine doing to VSS-import, we are using ssapi 8.0.50727.42.
As for commenting the logs: the following files were corrupted after the import, they all consisted of 4 binary zeroes, after import they were empty:
$/exe32/TstEdge/ucCmp.ctx
$/exe32/konfedge/frmadd.frx
$/exe32/knedge/Code.ctx
$/exe32/KfDialog/ucEnv.ctx
In VSS they are all marked as binary, but also with auto-detect encoding - seems to have been the default for these VB-files.
Note that the various errors "item with the same name or object id already exists" were caused by a previous abort of a VSS_import. Part of the folder structure had already been created before any files were imported. The problem with the small binaries also occurs in a brandnew DB. This is merely the newest import of 7 test-runs. Also the missing revisions listed at the end of the import log are mainly files that were marked with "do not keep older versions", the rest of them were VSS-corrupted (and VSS-fixed int he way VSS fixes these inconsistencies) at some earlier point in time in the day-to-day usage of VSS. These corruptions are, by the way, the main reason that we are evaluating alternatives to VSS.
On the machine doing to VSS-import, we are using ssapi 8.0.50727.42.