Home AOMEI Products Support

cannot restore because of path.....

I am trying to just restore to a new location or explore the backup. I just need some of the data in the back-up.

When I try any way of restoring I get this message:


Information Code:4164

The destination path is too long, please restore to original location or change a shorter path and try again.


I have tried restore to a shorter path "C:\restore" and still get the message.


Thaniks for any help!


Comments

  • Got any help on that?


    having same issue...

  • Got any help on that?


    having same issue...

  • Hello to all,


    We are so sorry for the late reply. As for this error, it refers to the string of the directory tree of the file which you want to restore is too long. You may have to restor to the original location. So if you are afraid of data lose, you may first copy the source file to another location and then restor the backup. 


    Best Regards,
    Kim
    AOMEI Support Team

  • Another possible, the destination path has not enough disk space for the restore.

  • I confirm this bug.


    Even restoring to a NAS where the path limit doesn't apply, AOMEI gives the error.

    So it's limited in the API AOMEI uses.


    Also path "\\?\D:\restore"  doesn't get accepted, which is a valid path. And this path isn't limited by the +/- 260 characters. 

    The possix/unicode path is limited by 32 000! characters. 

    Std Windows API does support this ! even the C++  fopen() supports this or standard .NET does support this. 


    Please accept the input we give, so it  would not be limited to the 260 characters. 


    How to fix now?
    I'm in need of the files inside the AFI file ! 



  • I confirm this bug.


    Even restoring to a NAS where the path limit doesn't apply, AOMEI gives the error.

    So it's limited in the API AOMEI uses.


    Also path "\\?\D:\restore"  doesn't get accepted, which is a valid path. And this path isn't limited by the +/- 260 characters. 

    The possix/unicode path is limited by 32 000! characters. 

    Std Windows API does support this ! even the C++  fopen() supports this or standard .NET does support this. 


    Please accept the input we give, so it  would not be limited to the 260 characters. 


    How to fix now?
    I'm in need of the files inside the AFI file ! 



  • Hello


    Is a resolution for this problem?


    I have a same issue.

  • @gipcomp

    I understand you also need some data restored from a backup.

    What kind of backup are we talking about?  System, disk or partition backups can be explored via explore image. Than you can copy your data with the windows explorer.

    Only with file backup to image you have to restore via a Save as.

  • We do file backup.  We try file backup to image via Save as and via restore but we receive a same message: "destination path too long". We try to restore on a clean windows OS ( in a same hardware machine).

  • Some other softwares do have this issue too. I tried and nothing can be done on AOMEI backupper. Can you use the other software for file backup (there the long path issue can be overcome), and keep AOMEI for other backups, as the other softwares also have many issues. And I hope you just did a test.

  • Wasn't a test. The files are in the backup but I can't restore because the path has more than 260 characters. If is a bug , nobody from AOMEI can do a patch ?

  • Do you still have the original data?

  • No.The computer was infected by Cryptolocker. Before this I made a backup to a NAS.Finally, I restored more than 99 % of my files.Utilities tab, and then explore image, take file by file, eliminate the files with long name, save us...and after 3 hour of work I save my work. Case solved.Thank's JohnnyboyGo for help. 

  • nharinton88  "I have tried restore to a shorter path "C:\restore" and still get the message."

    Please try to explore the image.

    gipcomp "Even restoring to a NAS where the path limit doesn't apply, AOMEI gives the error."  

    s for your problem, please deleteall "NAS.xml" in the  installation directory of thesoftware and under the path(C:\ProgramData\AomeiBR).

    And then please re-connect your NAS again.

    There is one thing we need to tell you that "ProgramData" is a hidden folder and you need toset to show all the hiddenfolders/files.


  • Please install Long Path Tool as this is the best software available right now.

  • Has this nightmare ever been fixed? I'm still getting it on 4.0.3, after a successfully-verified backup. I've tried all the BS suggestios, including shortening the path and restoring to the original directory. AOMEI, I can even uncheck the affected files so that your stupid program isn't supposed to attempt to restore them, and it fails anyway. Fix this. Now.

  • @SirAcid Please tick the option "Restore only files".

  • edited May 2017

    These workarounds are great ideas, but time consuming.  This is because restoring only files skips duplicate file names and requires manual restoration of files to their correct paths.  That is just not close to useable for large backups.  Also, specifying which files to skip manually, one by one, is very time consuming.  


    Aomei, is there any way to change your software to fix/prevent by allowing longer file path names?  

    1. If not, it would be important to add a warning to user that file path is too long, during initial backup.

    2. Another idea is to add a button in the restore wizard file selection screen that says, "deselect files / folders greater than x number of characters" and let user specify x.

    3. A third "fallback" idea is, during restore of "files only", don't skip files (i.e. don't skip and say, "This file exists, the recovery operation has skipped the file already:"), but instead rename them by appending a numeral at end or similar.  That way at least all files get restored.  Also, there would need to be an option to output the name and path of all files/folders in the backup so that the user could go through and put the file structure back together again manually.  This way it can be done, even if it takes the user hours.


    Implementing even the easiest of the above changes would cause less grief for users attempting to restore from backup and experiencing this issue.

  • @alamp Thanks for your suggestions, I will report these to our tech department.

Sign In or Register to comment.