SyncToy 2.1 ignores regular files after "path too long" RRS feed

  • Question

  • There is the well known bug of version 2.1, that files with paths exceeding a certain length can not be synchonized. Unfortunately in such a case ("Cannot read from the source file … ") SyncToy ignores all residual files in the same folder obviously, even if their path length is below the critical limit. These ignored files are not mentioned in any error message, not even in SyncToyLog.log. From the viewpoint of reliable backup I would call this a very severe bug.

    Please inform the developers.
    Thursday, February 25, 2010 5:40 PM

All replies

  • Hi, Wolfgangbeyer:

    I'm glad that you choose SyncToy, and I must say you are very circumspective to find this scenario. But what I should tell you is this kind of problem is not caused by SyncToy. As we all know, path in Windows has a limited length. So if the (FileFolderPath + FileName) run out of the length limited, it is not allowed by OS. But to think about another scenaro, if (LeftFileFolderPath + FileName) dose not run out of the length limited, which just because the LeftFileFolderPath is not so long. But RightFileFolderPath is long enough that (RightFileFolderPath + FileName) run out of the length limited. In this situation, if we sync from LeftFolder to RightFolder, what would be happened? Yes, SyncToy would not work cause (RightFileFolderPath + FileName) is longer than the length limit.

    So, my suggestion is not to set your folder level so deep and not to set your file name so long. To my knowledge, thepath in Windows can carry less than 128 charactors.

    • Proposed as answer by Ping Lu Tuesday, March 16, 2010 4:11 AM
    Thursday, March 11, 2010 10:12 AM
  • Use network drive mapping is another choice too.

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, March 12, 2010 9:26 AM
  • What a stupidness, you cannot advice to change the file/folder configuration as SyncToy wishes, I have my files in my drive and want these files in another drive as they are but I cannot take a backup due to this stupid bug.
    Wednesday, July 7, 2010 4:10 AM
  • I agree, this is a stupid bug and a stupid limitation. If I can have a long path name recorded, I should also could copy it!
    Wednesday, August 11, 2010 11:51 AM
  • Utterly non-sense bug. Completely agree - why allow having long names if you cannot copy them?
    Piyush Soni,Tata Consultancy Services, India
    Friday, October 8, 2010 9:05 PM
  • Danish,

    Your explanation is not consistent with observed behaviour of SyncToy 2.1 in Windows7. I went to the directory directly in explorer and manually copy the affected files to the another disk (with the same deep directory structure). The copy completed successfully.

    my CONCLUSION #1: The OS allows these long paths.

    my CONCLUSION #2: SyncToy could not manage these long paths (but surprising could record the whole path in the log file. This means the OS must have provided the path, thus supporting conclusion #1).

    I would like to recommend that you update your knowledge in Windows path length too. It is certainly more than 128 characters, since the days of Win95.

    I know that SyncToy carries no warranty but the sake of correctness, I am highlighting the inconsistencies between your inputs and my observations.


    Thank you.

    Wednesday, January 12, 2011 6:37 PM
  • I was wondering if SyncToy would be able to handle paths greater than MAX_PATH limitation imposed by Windows (which, BTW is 260 characters or 255 after the initial "c:\" and the NULL char at the end). There are other tools (including MS's own Robocopy) that is able to go beyond this limitation. You may be able to use the Universal Naming Convention (UNC) prefix of "\\?\" before the beginning of the path in order to have SyncToy ignore MAX_PATH, but since I haven't used SyncToy yet (I was looking in the forums for this exact info before trying it) I'm unsure whether this is a possible work-around...


    Edit: I forgot to mention that the MAX_PATH limitation is for XP and earlier. i'm unsure whether that is still a problem with Vista and Win 7. I do know that Robocopy now comes standard in Vista and Win 7, so manually copying files with long paths may revert to this application under the scenes, thereby allowing long paths to be used. I whole-heartedly agree that since MS has known about this limitation for many years, have already developed a different copying tool that ignores this limitation, why they would create a "new" tool that goes back to the old standards. Esp. when Windows automatically sets up user data in a directory structure that already has a long path: "C:\Documents and Settings\Administrator\My Documents\My Music\" occupies 62 characters, and if you're like me separating my music first by Artist directory and then by Album, you might very well exceed the limitation. Another option you may consider is to use the DOS command SUBST to create a virtual drive that points to a particular directory. For example, subst m: "C:\Documents and Settings\Administrator\My Documents\My Music\". Then with SyncToy, use m: instead of the longer path when creating the folder pairs.

    Monday, March 21, 2011 3:38 PM
  • apologies for brining this up - I have exactly the same problem in the latest 2.1, moving all data from old sever to VM and trying to ensure echo is keeping things upto from old to New server until I'm ready to flick the switch and make the VM live etc, (I could just copy the main folder but I need to ensure any updates are brought across right until the final stage) but because of this long file path error, I have no choice to look for another tool, as changing all paths and mapping drives to every folder just so that synctoy gets a little further is not an option !!

    To ensure ALL THE SAME data is captured and copied & tracked this doesnt seem like the best tool (for very basic structures yes, but not for corporate archives), I could ask the departments to re organise all their folders and reduce the path lengths, but If you are accountants and have folders for each year, each with long "working" paths this change will impact everyones saved windows folder shortcuts and existing mapped drives that the users have.

    Sunday, September 23, 2012 2:35 PM
  • Drive Mapping will do it as what is being said by Ping Lu.

    But in order for me to get away with that error I used third party software Long Path File and helped me out this long path file error.

    I don't know what could be the 'cause of this problem, through research I found out a solution. longpathtool(dot)com.

    Thursday, April 4, 2013 4:56 AM
  • Hi,

    SyncToy doesn't support path longer than 255 caracters. It's a known limitation.

    If you just want to mirror folders content (the SyncToy echo mode), you can use Echosync, a portable sync software which suports long path.


    Tuesday, August 6, 2013 3:55 PM
  • Agree with your OLD problem.  It still exists in 2013!!! 

    It is actually OK that this causes an error in my opinion, but not giving the user an option to skip that particular long file is ridiculous.  You could be trying to sync 20 gb of data, but one mis-named file at the 17 gb point can bollox up the mess.

    Stupid Synctoy!

    Friday, September 20, 2013 9:14 PM
  • Hi:

    This reply is nearly 4 years after the original topic was raised, so I think the problem is here to stay.

    I had just one file where the name was  quite long and it blocked the copy of the whole folder. I didn't want to discard SyncToy and try a different product just for 1 file, so I renamed the file to something short and relatively meaningless, which allowed SyncToy to work. As the original title of the file was important (a description of the photograph in the file), I modified the file properties(link: then read the section To add or modify properties that don't appear in the Details pane) and added the original filename to the Title properties - the Comments property may also be suitable. The contents of the Title properties is now shown as part of the metadata displayed when I hover over the filename in Explorer, which is acceptable for me. (Also I can choose to display the Title column in the Explorer Details display).

    Obviously this doesn't get to the root of the problem and I wouldn't advise it as a permanent workaround for any commercial production environment. However it's acceptable for me as I check the SyncToy log files every week or two by manually executing:

    c:\temp>findstr "Warning" "C:\Users\Administrator\AppData\Local\Microsoft\SyncToy\2.0\SyncToyLog.log"

    and looking for lines like

    Warning: 1 failures occured.

    I guess this process could be automated and the error log emailed if any lines found.
    Thursday, December 26, 2013 4:35 AM
  • Hi!

    using Windows 10 with the latest update, enabling Long-paths via Group Policy and having installed .NET Framework 4.7.2 (for applications using it), Windows himself and also applications using .NET Framework 4.7.2 are enabled to use Long-paths also in Windows - but SyncToy is NOT able to do so!

    It would be very courteous if the Publisher could provide SyncToy compiled with .NET Frameworl 4.7.2 and tested against Long-paths (also Windows Server 2016 is Long-path enabled).

    Best regards!


    Sunday, July 8, 2018 6:44 PM