9

According to this question, Windows 8 File History silently fails when a filename is too long. How can I be certain that all of my files have been backed up successfully? Is there any way to be warned when a backup is unsuccessful?

3 Answers 3

4

How can I be certain that all of my files have been backed up successfully?

You have to check it manually in event log under "Advanced Settings". Microsoft has just launched it, so there may be some bugs.

Is there any way to be warned when a backup is unsuccessful?

At the moment there is no automatic error report of back up failure (for example, if one of your folders is not backed up). You have to do it through event log.

enter image description here

enter image description here

5
  • Thanks! Can you check my edits to your post? I edited for clarity, but I want to make sure I didn't change your meaning.
    – Matthew
    Nov 7, 2012 at 17:04
  • 1
    @Matthew You can right click on the event and set up a task to have it warn you the next time it occurs. It says email and popup notifications have been deprecated, so not sure if that will work, but I'm sure you can figure out how to cutomize it with the other option (start program/script). Nov 7, 2012 at 17:24
  • So Event Viewer does log an error as I suspected. When I asked @Kang about it on the original question, he said there were no errors.
    – Karan
    Nov 7, 2012 at 21:34
  • @karan may be kang is missing something. If the folder is empty then it will not back up by file history and it will not generate any warning or error in that case.
    – avirk
    Nov 8, 2012 at 1:01
  • Well, no files, no point in file history, right? :) In his case though some files with long names were skipped, while others were backed up. Guess he just didn't look carefully enough in Event Viewer.
    – Karan
    Nov 8, 2012 at 14:36
4

Actually in Windows 8.0, long file names are NOT skipped. They may appear to be missing when you look directly at the FileHistory\\\Data folder structure on the physical backup media, but this is not the whole story. Long-named files are renamed and placed in a $0F subfolder folder you'll find on the physical media alongside any other drive letter folders you are backing up.

Use the File History recovery GUI instead and you will find all your long-named files automatically re-integrated into your familiar folders structure.

This design does weaken one of the key benefits of the tool - being able to work with the backup media directly instead of an unreadable monolithic archive. You still can, but those long filenames aren't in their correct location and have been renamed (though file types and content are not affected so you can still access the data). Nevertheless, there are NO silent omissions. It's all copied, you just have to use the File History recovery GUI to see the complete picture.

1
  • This is not fully correct! If the total path length is too long, the file is skipped and the error is logged, as seen in this answer May 28, 2019 at 19:13
1

It seems like the behavior is a bug, so I doubt there is any way to make it warn you.

You could make some script to test whether all your files are named using 260 - 25 = 235 chars or less, but other than that I don't think there is a solution.

The best course of action would probably be to report this bug to Microsoft.

1
  • 1
    It's not a bug, it's by design. Otherwise it would not be logged by Event Viewer with a proper Event ID, error message etc. @Matthew: Also, there's obviously a way to make it warn you. Since Event Viewer logs it, you can set a Task trigger for the ID and make Scheduler send a mail or display a message or anything you want whenever that error is logged.
    – Karan
    Nov 7, 2012 at 21:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .