locked
VSSConverter DOS 8.3 name issue

    Question

  • An error TF203013 ('The path [ItemSpec] is in the DOS (8.3) short path format and is not supported') has been halting my migration process. Restarting using incremental migration returns the same error. A google for the error code yields nothing.

    The item (and the folder it was in) - $/Internal/CompileBasic/Downlo~1.avi -  was deleted and purged before the migration process. I had run the Sourcesafe analyze utility twice before starting the migration, and no significant errors appeared in the migration analysis.

    I have started another sourcesafe analyze on the database, in the hope that might fix the issue. Failing that, could anybody tell me if it would be worth being more detailed in the project source section of the settings.xml? At present, it only specifies $/Internal, maybe specifying folders deeper in the tree may help?

    We have a very large SourceSafe database of around 20Gb (yes, I know!) and the length of time it takes to backup/copy/analyze etc makes it difficult to keep starting over.

    Here is the relevant snippet from the log. It repeats until a Thread Abort error is thrown.

    Code Snippet

    [VersionControl,  Warning,  19, 2008/01/28 18:07:25.842] 0 updates
    [VersionControl,  Warning,  19, 2008/01/28 18:07:25.936] 0 updates
    [VersionControl,  Warning,  19, 2008/01/28 18:07:26.155] Starting Pend Changes, RequestType Add, request.Length 200
    [VersionControl,  Error,    19, 2008/01/28 18:07:26.436] Exception: System.Web.Services.Protocols.SoapException
        Message: TF203013: The path $/Internal/CompileBasic/Downlo~1.avi is in the DOS (8.3) short path format and is not supported. Enter a full path to the item and try again.
        Stack Trace:    at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at Microsoft.TeamFoundation.VersionControl.Proxy.Repository.PendChanges(String workspaceName, String ownerName, ChangeRequest[] changes, Int32 pendChangesOptions, Int32 supportedFeatures, Failure[]& failures)
       at Microsoft.TeamFoundation.Converters.VersionControl.Common.HatterasWrapper.PendChangesInternal(ChangeFileInfo[] fileChanges, ChangeRequest[] requests, Workspace ws, String[]& serverPaths)
        Help Link:
        BaseExceptionMessage: TF203013: The path $/Internal/CompileBasic/Downlo~1.avi is in the DOS (8.3) short path format and is not supported. Enter a full path to the item and try again.

    [VersionControl,  Error,    19, 2008/01/28 18:07:26.436] SubCode.Code.Name: InvalidPathException
    [VersionControl,  Warning,  19, 2008/01/28 18:07:26.451] Repository is down. Retrying...
    [VersionControl,  Warning,  19, 2008/01/28 18:07:26.451] Repository is back
    [VersionControl,  Warning,  19, 2008/01/28 18:07:26.936] Starting Pend Changes, RequestType Add, request.Length 200
    [VersionControl,  Error,    19, 2008/01/28 18:07:26.952] Exception: System.Web.Services.Protocols.SoapException
        Message: TF203013: The path $/Internal/CompileBasic/Downlo~1.avi is in the DOS (8.3) short path format and is not supported. Enter a full path to the item and try again.
        Stack Trace:    at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at Microsoft.TeamFoundation.VersionControl.Proxy.Repository.PendChanges(String workspaceName, String ownerName, ChangeRequest[] changes, Int32 pendChangesOptions, Int32 supportedFeatures, Failure[]& failures)
       at Microsoft.TeamFoundation.Converters.VersionControl.Common.HatterasWrapper.PendChangesInternal(ChangeFileInfo[] fileChanges, ChangeRequest[] requests, Workspace ws, String[]& serverPaths)
        Help Link:
        BaseExceptionMessage: TF203013: The path $/Internal/CompileBasic/Downlo~1.avi is in the DOS (8.3) short path format and is not supported. Enter a full path to the item and try again.

    [VersionControl,  Error,    19, 2008/01/28 18:07:26.952] SubCode.Code.Name: InvalidPathException


    Monday, January 28, 2008 11:23 PM

Answers

  • The check to prevent ambiguous 8.3 names was added in 2008, correct.  Glad you got it working.
    Wednesday, January 30, 2008 12:57 AM
    Moderator

All replies

  •  

    Ok, the 8.3  file in question (Downlo~1.avi) had been moved to another project and still existed in the VSS database. I destroyed the file and tried to start again, but it seems there is no easy way to start a fresh migration. Agreeing to an incremental migration caused the same error.

     

    I had a look in the VSStoVersionControlConverterDB on our SQL Server and found that the SCMHistory and VerificationTable tables contained details of files from the VSS database, so presumably VSSConverter initially populates these tables, and on an incremental migration uses this existing data to start from the point it left off.

     

    Downlo~1.avi was referenced in a couple of rows, so i deleted the rows on which it appeared from both tables, and the migration has now continued. I'm slightly concerned about whether this hack will have any knock-on effect, but I was running out of things to try.

     

    Interestingly (and annoyingly), I'd run a test migration a month ago on TFS2005 (this issue is with 2008) with exactly the same VSS database and I came across no such error. If it is true that TFS cannot handle 8.3 names then it would be nice if the analyze phase of the converter could offer some kind of warning!

    Tuesday, January 29, 2008 11:30 AM
  • The check to prevent ambiguous 8.3 names was added in 2008, correct.  Glad you got it working.
    Wednesday, January 30, 2008 12:57 AM
    Moderator
  • To clarify, all versions of TFS (and anything else that uses the .Net filesystem APIs) have trouble handling 8.3.  Adding them usually works, but operations like Get and Unshelve can fail in strange ways or overwrite legitimate files that have ambiguous names.  In TFS 2005 this affected several customers, so in 2008 we blocked them from being added in the first place.
    Wednesday, January 30, 2008 6:42 PM
    Moderator
  • I'm getting this error while migrating in TFS 2008. I know there are a lot of them to come in my VSS database. Any workaround?

     

    Also, are you saying that "in 2008 we blocked them from being added in the first place" that the files won't migrate over?

    Monday, June 30, 2008 4:34 PM
  • I am also encountering this issue, and I would prefer NOT to install a service pack that is still in beta (TFS 2008 SP1) onto a production server.  I deleted the rows with the offending filename from my VSSToVersionControlConverterDB's dbo.VerificationTable table, and also attempted to recreate, delete, and purge the file it is talking about but it seems there are still entries in the history or I'm not purging correctly.  The file does not exist in my current view of the VSS database, and I can't figure out how to remove it from the history so that it won't be migrated.

    EDIT: I also deleted the row containing the offending filename from the dbo.SCMHistory table and was able to get past the error.

    EDIT: Duh #2: TFS 2008 SP1 is no longer in beta: http://www.microsoft.com/downloads/details.aspx?familyid=9E40A5B6-DA41-43A2-A06D-3CEE196BFE3D&displaylang=en
    Monday, September 29, 2008 7:31 PM
  • You can follow this KB article for the details on how to change the TFS settings temporarily to allow DOS8.3 name to be added to TFS server. Remember to change it back after VSSConverter is done.

    I have also written a blog about the issue.

    Thanks,
    Pei
    Tuesday, October 28, 2008 3:35 AM