BackupAssist Support Forum

Posted: **Thu Mar 31, 2016 9:47 pm**

Backup worked fine but restore failed. Got a "path to long" error during restore.

This can happen at all time, because data is stored on the file server under D:\share\projects
The clients maps this to e.g. P:\
So the client see's a shorter path, than it is actually used.
And anyway, there is no problem to create file and directory names longer than 260 characters.
Please fix this. (Using version 9.2.3)

Destination check Details: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Stack trace: at System.IO.PathHelper.Append(Char value)
at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
at System.IO.Directory.CreateDirectory(String path)
at CortexIT.BA.Restore.Progress.RestoreProgressController.StepDestinationCheck(Activity activity)

Posted: **Thu Mar 31, 2016 11:06 pm**

Hello,

It's Michael Jones from support.

This error is actually a Windows limitation which doesn't allow file name lengths to be larger than 248 characters from start to finish.

The only way to resolve this error is to reduce the number of characters in the file path which the files you're backing up that are over this limit.

That means the fully qualified path not a the path of a mapped location.

I refer you to the MSDN article:

https://msdn.microsoft.com/en-us/library/aa365247.aspx

Posted: **Mon Apr 11, 2016 5:07 pm**

Thats not true. See in the sent link of the MSDN article:

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

So there is a limitation, but you can avoid it. As its been done in the backup engine.

Posted: **Tue Apr 12, 2016 4:00 am**

Hello,

Making that kind of modification would be outside our scope of the backup or restore.

We would not make modifications inside the backup process to something like the file path, that would be up to you.

Just like we would not alter the format of a incompatible drive from FAT32 to NTFS.

Configuration changes on the server are the customers responsibility.

Posted: **Tue Apr 12, 2016 5:49 pm**

You don't understand.
BackupAssist supports long file name during backup. Only the restore doesn't work.
Besides, there are no modifications necessary on the server to support long file names.

Posted: **Tue Apr 12, 2016 10:06 pm**

Hello,

I never said anything about backing up, the question is in regards to deleting...

From https://support.microsoft.com/en-us/kb/320081

You cannot delete a file or a folder on an NTFS file system volume

Files exist in paths that are deeper than MAX_PATH characters

You may not be able to open, edit, or delete a file if there are issues with the file path.
Resolution 1: Use an auto-generated 8.3 name to access the file

To resolve this issue, you may want to use the auto-generated 8.3 name to access the file. This resolution may be the easiest resolution if the path is deep because the folder names are too long. If the 8.3 path is also too long or if 8.3 names have been disabled on the volume, go to Resolution 2. For additional information about disabling 8.3 file names on NTFS volumes, click the following article number to view the article in the Microsoft Knowledge Base:
121007 How to disable the 8.3 name creation on NTFS partitions
Resolution 2: Rename or move a deep folder

Rename the folder so that the target files that are deeper than the MAX_PATH no longer exist. If you do this, start at the root folder (or any other convenient place), and then rename folders so that they have shorter names. If this step does not resolve this issue (for example, if a file is more than 128 folders deep), go to Resolution 4.
Resolution 3: Map a drive to a folder in the structure of the path

Map a drive to a folder inside the structure of the path of the target file or folder. This method shortens the virtual path.

For example, suppose you have a path that is structured as follows:
\\ServerName\SubfolderName1\SubfolderName2\SubfolderName3\SubfolderName4\...
In this path, the total character count is over 255 characters. To short the length of this path, to 73 characters, map a drive to SubfolderName4.
Resolution 4: Use a network share that is as deep as the folder

If Resolution 1, 2, and 3 are not convenient or do not resolve the issue, create a network share that is as deep in the folder tree as you can, and then rename the folders by accessing the share.
Resolution 5: Use a tool that can traverse deep paths

Many Windows programs expect the maximum path length to be shorter than 255 characters. Therefore, these programs only allocate enough internal storage to handle these typical paths. NTFS does not have this limit and it can hold much longer paths.

You may experience this issue if you create a share at some point in your folder structure that is already fairly deep, and then create a deep structure below that points by using the share. Some tools that operate locally on the folder tree may not be able to traverse the whole tree starting from the root. You may have to use these tools in a special way so that they can traverse the share. (The CreateFile API documentation describes a method to traverse the whole tree in this situation.)

Typically, you can manage files by using the software that creates them. If you have a program that can create files that are deeper than MAX_PATH, you can typically use that same program to delete or manage the files. You can typically delete files that are created on a share by using the same share.

In regards to your comment regarding there not being any modification necessary, you have it in your quote:

This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

If you want to make the necessary changes to the structure of the data or the modifications suggested above, that may get you there, but currently deleting data from a backup with a file path greater than the MAX_PATH limit is not supported.

Posted: **Tue Apr 12, 2016 10:11 pm**

Deleting? OK, whatever.
You should move this topic to feature requests.

Posted: **Tue Apr 12, 2016 10:13 pm**

Hello,

I can certainly do that for you at least.

BackupAssist Support Forum

Path to long error during restore

Path to long error during restore

Re: Path to long error during restore

Re: Path to long error during restore

Re: Path to long error during restore

Re: Path to long error during restore

Re: Path to long error during restore

Re: Path to long error during restore

Re: Path to long error during restore