Vault can't undo its own action

Perry · Post by **Perry** » Mon Jun 27, 2005 2:11 pm

"The path is too long after being fully qualified. Make sure path is less than 260 characters."

I'm trying to undo some checkouts I made earlier.

I don't know what to do now?

Perry · Post by **Perry** » Mon Jun 27, 2005 2:22 pm

Whoops, I thought that that error message meant it was failing, but it worked -- kind of -- now all the files are no longer checked out, and half are marked renegade.

When I do a Get Latest Version to try to fix those Renegade files, I get a "Locally Modified File" dialog, which has a multiline label on top which is overflowed, so I cannot read the paths. That should be a readonly edit box probably. (It looks really terrible, because the bottom line is cut off halfway vertically.)

Perry · Post by **Perry** » Mon Jun 27, 2005 2:24 pm

GetLatestVersion failed on one file:

Local file update for $/vault/path/filename failed: System.IO.PathTooLongException: The path is too long after being fully qualified. Make sure path is less than 260 characters.
at System.IO.Path.nGetFullPathHelper(String path, Char[] invalidPathChars, Char[] whitespaceChars, Char directorySeparator, Char altDirectorySeparator, Char volumeSeparator, Boolean fullCheck, String& newPath)
at System.IO.Path.GetFullPathInternal(String path)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
at VaultClientOperationsLib.WorkingFolder.BackupFile(String filename)
at VaultClientOperationsLib.WorkingFolder.UpdateWorkingFile(VaultClientFile file, Int64 targetVersion, Int64 displayVersion, MergeType merge, DateTime dt, Boolean makeBackups, OverwritePrompt PromptData)
at VaultClientOperationsLib.WorkingFolder.UpdateWorkingFile(VaultClientFile file, Int64 targetVersion, Int64 displayVersion, MergeType merge, DateTime dt, OverwritePrompt PromptData)
at VaultClientOperationsLib.ClientInstance.ProcessGetFileRequests(GetFileInfo[] infos, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, Boolean updateHiddenFilesOnly, String ancestorFullPath, Boolean flat, String ancestorDiskPath, OverwritePrompt PromptData, Boolean isLabelGet, String currentPathToLabelItem, Int64 labelID, Boolean isRetry)

lbauer · Post by **lbauer** » Mon Jun 27, 2005 2:30 pm

Most likely you are running into a path length limitation in .NET.

See this for more info:
http://support.sourcegear.com/viewtopic.php?t=1965

dist0rti0n · Post by **dist0rti0n** » Wed Mar 14, 2007 12:48 pm

Does SourceGear have any plans to address this problem in Vault 4 or a future revision of the 3.0 codebase?

Post by **jclausius** » Wed Mar 14, 2007 2:16 pm

There is nothing we can do about this, as the Vault code has no such coded restrictions.

The fix to this problem will be up to Microsoft to remove the restriction in the underlying .Net CLR.

ICOM · Post by **ICOM** » Tue Jan 15, 2008 5:44 pm

MS already has Unicode functions for allowing up to 32000 character paths. Note that you can create files not accessible via the normal API calls when using these, causing such annoying effects such as the inablitity to delete the file from windows explorer.
See http://msdn2.microsoft.com/en-us/library/aa365247.aspx for more info.

Post by **jclausius** » Wed Jan 16, 2008 9:13 am

As I stated before, the Vault code itself has not imposed this limitation, but rather this is an error thrown by the .NET Framework.

Now, many versions of .NET Framework have been released since the original post. I haven't tried it, but I wonder if MS has fixed these problems in the later releases.

SourceGear Support

Vault can't undo its own action

Vault can't undo its own action

It kind of worked

.net exception trace back for failing file