Windows 10: filehistory old versions

when running the version cleanup does it only look at backup files for the current PC or all PCs under filehistory on the same backup drive?


also there are 3 versions of this PC under filehistory can I just delete the 2 unused ones?

:)

 

FileHistory in Windows 10 Build 17763.253 completes incomplete

Hi,



Thank you for writing to Microsoft Community Forums.



File History only backs up copies of files that are in the Documents,
Music, Pictures, Videos, and Desktop folders and the OneDrive files available offline on your PC. If you have files or folders elsewhere that you want backed up, you can add them to one of these folders. I would suggest you to format the new
drive and then try to initiate file History back up once again.



You can try resetting File history. To reset file history, disable (turn it off) it and follow the steps mentioned below:

1. Go to the folder %UserProfile%\AppData\Local\Microsoft\Windows\FileHistory. You can copy and paste this path to the address bar of File Explorer.
   
2. Delete all files and folders you see.
   

Once you perform the above steps, you can try setting up file history once again. If you need any additional assistance, please reply back with the exact error message.



Regards,

 

Bug > FileHistory/Credential Manager

Hi,

I don't know where to report this so please guide me.

I use FileHistory to back up all my Windows 10 PCs. Target backup location is a Synology NAS.

FileHistory uses the Credential Manager to log into the NAS and store the backup files. To me that's a huge problem and therefor a serious bug.

If I have to store credentials in Credential Manager for FileHistory to be able to store the backup everyone can access that backup data.

I should not be difficult for ransomeware to ask the Crendential Manager to browse the backup location and then encrypt it. It's pretty ironic that this is a valid scenario - you would think your FileHistory backup is where you restore all data from when it
has been encrypted - but that's not the case when the entire backup is encrypted.

I suggest that FileHistory uses it's own password vault instead of Windows Credential Manager. It's a huge flaw that the Credential Manager is being used for backup purpose and it defeats the purpose of having a secured backup when everyone can access the
backup files. The goal must be to only grant the backup client access to the backup location.

// peter

 

What is the $0F folder in FileHistory?

Hi Igor,

Good suggestion...

First off. DON'T DELETE THE $0F FOLDER. It appears the $0F sub-folder in FileHistory is absolutely required.

The link you sent helped me come to this conclusion. I have a BS degree in Information Systems. So, I have a good understanding (all be it primitive) of how DOS works. DOS is still the original OS system (since improved) under which all versions of Windows
still operate). I still write and use DOS based C programs that manipulate files and paths in all versions of Windows.

All that stuff (in that link you provide in your first reply) about people complaining about missing files makes sense with this explanation. Those missing files were probably in their $0F folder.

I did some comparisons as you suggested.

I'm thinking the FileHistory program caches (in RAM memory) groups of folders and files before sending them to the backup drive. When the cache space gets filled, they send the cache in one write operation to the backup drive. Then it adds the remaining files
(that were not cached from this last folder) to the next cache. Those files get tagged and written to the $0F folder (under a reference number) in the next cache write operation. There appears to be exceptions on how the FileHistory program handles some (not
all) HTML files and some URLs and some other file types. I found a lot of these in the FileHistory $0f sub-folders. And there's probably other exceptions as well because some HTML files and some URLs that were still sent to the correctly named path and folder.

I say this because the particular folder I referenced in which I found a file match, 4 files where sent to the correctly named folder in the correct path in FileHistory and the other 108 files in that same folder where written to a numbered $0F folder. The
very next folder in that same C:\ drive path had an even longer folder name and all the files lengths were the same in both folders. Thereby, the path + file names was even longer in that next folder. But all the files in that next folder were written to the
correct path and folder in FileHistory.

Maybe I'm all wet on this. But it's my best guess.

Thank you for your help. You helped me to find something that makes sense to me at least.

Rob