File History and the $OF Folder on my External Drive

According to some other forum posts, $OF holds files whose pathname is too long to be stored on your backup device.  My guess is that "OF" stands for "OverFlow". 

File History tries to do a "mirror" copy of your user files and folders, preserving directory and file names.  Windows has a 255-character limit on all pathnames, though, and File History adds a longish timestamp to all filenames when it makes its copy, so if you have a file near the name length limit, Windows will have to save it to a different name when it makes the copy.  Also, if you back up to a network drive, Windows has to prepend the server and share names to each filename to build the UNC path, so the apparent length cutoff may end up being much less than 255 characters.  If you've got long directory names or deep trees, it could be that a lot of your files end up in $OF.

See:

http://answers.microsoft.com/en-us/windows/forum/windows_8-files/file-history-appears-to-be-missing-folders/43873887-d16e-4c05-a622-c7b25003f5d2?page=2

http://superuser.com/a/701883/399577

(edit: make links clickable)

One last followup, even though I think I'm the only one following this thread. I got frustrated this morning to find out that the number of files/folders in $OF returned to what it was on Monday. 

So finally I did what I should've done in the first place, instead of looking at the files exactly as they appear on the external harddrive in File Explorer...I browsed through the files using the File History Restore Personal File option. When I did this I found all files appear properly, even those that are renamed and stored in the $OF folder of the backup. 

So at the end of the day, it's not clear what the $OF folder is or why files end up there...but the files can still be accessed and recovered easily through the File History window as opposed to going into the external drive manually.

>Windows has a 255-character limit on all pathnames

That's not quite correct. Some legacy code in Windows has a limit - the so called MAX_PATH problem harking back to the very early versions of the Windows API (application interface) when memory was a much scarcer resource than it is now. MAX_PATH is a hard-coded constant and is actually 260 ASCII characters.

Most file system can handle very deep (long) paths although there is sometimes a character limit on each individual folder - certainly the ones used on anything in the last 10 years. Which is where the problem occurs. You can create very deep (long) paths that some applications can't handle because they are still using the legacy API.

Bizarrely, that most modern of application, PowerShell, which Microsoft puts a lot of effort into, is still hampered with MAX_PATH which is most perplexing considering it's a relatively modern bit of software.

I'm guessing the File History developers decided to play safe and implemented a system whereby they handle long paths in a way that covers all bases. However, as File History is only on relatively modern operating systems, the decision is a little difficult to defend.

This is a "tip of the iceberg" problem :-) Throw in spaces, Unicode and special characters and you could devote a whole career to this topic!

Yes I found this folder annoying as well.

A few points:

• Does not appears to be due to long names. I have longer file names located in the C folders and short names placed in the $OF folder.
• Files in this $OF folders will not be located in the C folder. Your files will be in one folder or the other.
• The $OF folder renames files and places them in random folders making it hard to search your files.

HOWEVER.......

If you browse through the backup app in windows 10 by clicking on "restore files from a current backup" you will notice that all your files are there in the correct names AND in the correct location regardless if they are placed in the C folder or the $OF folder.

Suggest probably just using the App to restore files rather than the old fashioned copy and paste. In any case they also seem to add a time stamp to the file names on the HDD which is also annoying if you wanted to just copy and paste.

I guess the good old days of simply having a duplication of your files on a HDD that you manually copy and paste are gone.

Disappointing that I can't seem to find an answer for this anywhere. All I can find is a few other people who have posed the question on various forums without anyone being able to get to the bottom of it.

Since the contents of the $OF folder have not changed all day despite multiple runnings of file history, I presume all the files that ended up there are there to stay. 

One other thought I had, since the first thing that comes to mind when I see the folder $OF is offline...I thought maybe windows has an issue with how it handles files when the external drive is offline or unavailable. So I tried creating a file when the external drive was turned off, and attempted to run File History...and I got the message that the files would be stored locally until the drive was available again. I then turned the drive on and ran File History again...seeing if the newly created file might end up in the $OF folder...but Windows did properly catch the file and get it in the right spot in the C folder.

I still think the $OF may be files where there was an issue syncing/copying to the external drive. Given that our drive is a wireless one, its certainly possible the connection was interrupted at some point during the initial sync. I may try deleting the backup on the external drive and trying running FIle History again to create the backup from scratch. If that doesn't work and no one can help me out on what's going on...I'm just going to abandon using File History as a backup agent...sounds like there's enough issues with it that its worth looking for third party software to do the job.