Unhandled exception during VSS import

[stevek2]

I'm running Vault v5.0.4, and trying to perform a VSS import on a 13-year-old VSS database. I've run analyze, etc, pruned & destroyed a lot of unneeded files in VSS. I successfully performed an import about a week ago, but then we decided we imported more than we really needed, so I decided to delete that Vault repository, and used the VSS archive tool to archive and delete versions older than 5 years ago; however when I tried to import this trimmed database, it failed, leaving the Vault repository with a valid folder tree but no files. The import log shows an unhandled exception "The file exists". Below I've included the tail end of the import log. I can't tell if the exception is referring to a temp file that exists (since GetTempFileName() is in the stack trace), or that the file already exists in Vault. As far as I can tell, the server did not run out of disk space, and there are valid TEMP directories both for Windows and VSS.

========================================
Change set type: CreateFolder
Adding to transaction: $/WANLinks/SplitDriver/Tools/Latest/Tools/Dense/libtools - $/WANLinks/SplitDriver/Tools/Latest/Tools/Dense/libtools
Transaction succeeded.
Archived versions of $DxbMemDump ($/WANLinks/SplitDriver/Tools/Latest/Tools/DxbMemDump) at 3/4/2002 11:54:34 AM
Change set type: CreateFolder
Adding to transaction: $/WANLinks/SplitDriver/Tools/Latest/Tools/DxbMemDump - $/WANLinks/SplitDriver/Tools/Latest/Tools/DxbMemDump
Transaction succeeded.
Archived versions of $DxbQueueDump ($/WANLinks/SplitDriver/Tools/Latest/Tools/DxbQueueDump) at 8/9/2002 4:23:02 PM
Change set type: CreateFolder
Adding to transaction: $/WANLinks/SplitDriver/Tools/Latest/Tools/DxbQueueDump - $/WANLinks/SplitDriver/Tools/Latest/Tools/DxbQueueDump
Transaction succeeded.
Unhandled exception during export: The file exists.

Trace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.__Error.WinIOError()
at System.IO.Path.GetTempFileName()
at VSSImport.WizardForm.PrepareFileForTransaction(Revisions& rev)
at VSSImport.WizardForm.ExportPassTwo(Hashtable vssUsers)
at VSSImport.WizardForm.Export()
Logged out of the Vault Server.

Finished Export. 9/2/2010 11:44:23 AM
Connected to Vault.
Deactivating Charliek.
Deactivating Chrism.
Deactivating Jbartley.
Import Complete!
Time to complete import: 00:01:28.4056842
VSS Database closed.

[Beth]

When you archived off a portion of your VSS database, did you restore that to a new blank VSS database?

After the restore of the archive, did you run analyze again? If not, try running the following on the restored archive (restored to a new blank VSS database) twice:

Code: Select all

analyze -C -D -F -V4 C:\path to VSS database\VSS\Data 

If you continue to receive any error warnings after the second run, let me know.

What VSS automation component are you using? Instructions for finding the automation component version are posted here: http://support.sourcegear.com/viewtopic.php?t=1510.

Make sure you're familiar with the following KB articles before importing:
Tips for a Successful VSS Import
Options for a VSS Import
Importing a solution or project that uses IDE Integration

[stevek2]

No, I selected the option to archive old versions and them delete them from the VSS database. Then I imported that pruned database into Vault. I ran analyze multiple times on the database before the archive, and got no errors. But I didn't run analyze after the export, so I re-ran analyze twice (fixing a number of minor issues), and then re-ran the import, with the same result -- an exception "the file exists" and no files in the Vault repository.

I think I'm following all the VSS import recommendations.

I'm running v6.0.96.4 of the SSAPI.DLL file - I think this is 6.0c with hotfix, correct?

[Beth]

Did you make a backup of your VSS database prior to the archive? This might give more options if you have that available.

I'd like to have you try the following:
1) Create an archive of the VSS database, but don't choose the option to delete. Just a basic archive of the entire thing to a file.
2) Using the VSS admin tool, create a new blank VSS database.
3) Restore the full archive to the new VSS database.
4) Create a new blank repository in Vault.
5) Perform a VSS import to the new blank repository, then report your results.

[stevek2]

Okay, now I'm really puzzled. I originally was able to import a VSS database, but the resulting Vault repository was full of stuff we really didn't need, so I attempted to prune the VSS database (either by deleting things I didn't need to import, or archiving off old history). When I then attempted to import the pruned database, I got the "The file exists" exception already described.

I then tried about a dozen different things - restoring the VSS database from backup, deleting less, archive/restore, etc, etc, and each time the Import failed with the exact same exception, even though analyze reported that the VSS database was fine. So I gave up on this first database, and just decided to go with the initial import I had done.

Then I moved to import a second database, this one having very large individual files but very little history, very few labels, and almost no sharing, branching or pinning. Analyze passed fine on this database, but the Import again fails with the exact same exception.

So now I believe that somehow the import process is simply broken on our server. Again, I've followed all the "Vault Import" advice I can find, and still I get this exception on every import I try.

How do we diagnose why this exception is occurring and what it means?

[Beth]

How large is each of the VSS databases you are importing? If they're not very big, it might be in your best interest to not try reducing the data.

I got the "The file exists" exception already described.

On that error you would need to import to a new blank repository instead of the one you already imported all the same data to.

Did you try the archive/restore I suggested to a new blank VSS database? I don't know if that's what you were referring to when you said you restored a backup, or if you just had a backup of the entire database that you restored.

If you've performed the instructions exactly as I had them, then it might be good for us to try and take this offline so that I can provide more help with this. Just send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread.