2

I just activated Windows File History, but it won't work. It loads for a surprisingly short time when I tell it to "execute now". When I look in the event journals, I see that for every time I tried, there is an error under event number 201:

Impossible d’analyser les modifications des bibliothèques utilisateur et d’effectuer une sauvegarde des fichiers modifiés pour la configuration C:\Users\Azma\AppData\Local\Microsoft\Windows\FileHistory\Configuration\Config

Which roughly translates to:

Unable to analyse modifications on user libraries and to save modified files for configuration C:\Users\Azma\AppData\Local\Microsoft\Windows\FileHistory\Configuration\Config

I've had user folder permission issues recently, which I thought the Microsoft technician had just fixed by applying to the whole Users folder total control permissions for my account. Indeed, whilst it couldn't before, now, the Windows Store can install applications.

But he did that on D:\Users, which contains folder Azma, which is my user folder. Not on C:\Users, which contains the symbolic link Azma, which points to D:\Users\Azma. In short, he applied it on the real folder, not the symlink.

So I tried to apply it to C:\Users, but it gave me an error, saying it was unable to propagate settings to the "Application Data" folder.

But perhaps the permission issue / symlink is not the problem. I don't know at all, and I'm pretty confused about this.

4
  • The symbolic may be the reason why File History can't work correctly. Why do you have your user profile on another drive (disk D) rather than the system disk C? Commented Feb 3, 2013 at 16:30
  • @Alexey In theory, symbolic links are supposed to work just as if the folder were still there... Maybe it's because of that; maybe I did it wrong, but what's sure is there's supposed to be a way to make things work properly despite the symbolic link. Anyway, the reason for the symlink is that the C: drive is a 128 GB SSD, which means a) its space is quite limited, so things like music and videos should go elsewhere, and b) how long it lasts depends very much on how many writes are made on it, which means frequently overwritten files such as the AppData folder should go elsewhere.
    – Ariane
    Commented Feb 3, 2013 at 18:30
  • I do not have symbolic links, but the same problem. After moving the contents of some of the folders the file history worked again. Now I try to find out which file/folder caused the problem, but finally it was not a symbolic link.
    – mgutt
    Commented Apr 14, 2016 at 13:53
  • I believe the English version of that 201 error is "Unable to scan user libraries for changes and perform backup of modified files for configuration" which is mentioned in this SU post.
    – User5910
    Commented May 19, 2021 at 17:48

2 Answers 2

3

Symbolic links, or Junction points, are usually transparent for applications. But they're not regular folders.

Backup applications are those apps for which symbolic links are not transparent.

File History operates on file system level, it saves some data on the file system, and your symbolic link points to another drive. That can cause issues with backup software.

Since File History backups libraries, you can leave your user profile on the SSD drive and then remove the default folder from the libraries and add the folders on D: drive into the libraries. And you can keep AppData as symbolic link to a folder on D: drive.


You can also move your users profile to D: drive completely.
You might also want to move ProgramData folder and Public profile to D: drive.

Or you can change the default location of user's profiles and then create a new account for yourself. The complete step-by-step guide: How to Change the Default Location of a User Profile in Windows 7 and Vista.

Do not forget to create a backup of your data, or better a system image to restore everything if something goes wrong.

Default location of user's profiles:

  1. Start Registry Editor by typing regedit on the Start screen and pressing Enter.
  2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList key.
  3. With ProfileList selected in the tree on the left, right-click ProfilesDirectory on the right pane and then click Modify or simply double-click ProfilesDirectory.
  4. Change the default value of %SystemDrive%\Users to D:\Users.
  5. Create a new user account, and its profile would be located under D:\Users.

Change location of existing user profile:

  1. Log on to an administrator account other than the account you want to move.
  2. Copy the profile of the user you want to move.
    In your case, you simply need to remove the symbolic link in C:\Users.
  3. Open Registry Editor by typing regedit on the Start screen and pressing Enter.
  4. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList key.
  5. Expand ProfileList key and look through each S-1-5- until find your user name and path in the Data column on the right pane in ProfileImagePath value.
  6. When you found it, right-click ProfileImagePath and then click Modify or simply double-click ProfileImagePath.
  7. Type the new path, for example D:\Users\Azma. Click OK to save the settings.
  8. Now you can log in to the account whose profile was just moved.
6
  • Haven't done it yet, but it sounds like just what I need. Thank you very much.
    – Ariane
    Commented Feb 4, 2013 at 20:00
  • Sorry for the long delay; I actually waited until I reinstalled Windows fully to apply this. I have one question. After moving the default user profile directory to D:\ and creating a fresh user whose profile is on D:\, should I take some measures to redirect C:\Users to D:\Users in case some application thinks it's always on the system drive? If so, how would I do that? Symlinking would require me to delete the Users folder first, which is either unadvisable, either impossible, I believe.
    – Ariane
    Commented Jun 3, 2013 at 20:06
  • Regardless, tested and approved! Though an answer to the little question above would be a great bonus!
    – Ariane
    Commented Jun 5, 2013 at 5:18
  • Of course, it's possible that a bad written app would consider user profile must be in C:\Users. On the other hand, there's more issues to moving C:\Users to D: completely. I'd leave it as is. If you're concerned, occasionally you can monitor files created in C:\Users, and then you can move them to D: and symlink the original location. Don't forget about C:\ProgramData where apps store data shared between the users. It might make sense to move it to D: too, or just parts of it via symlinks. Commented Jun 6, 2013 at 8:03
  • I've already moved ProgramData in the registry, and left the original folder in C: as is, after copying its contents over to D:. What I'm worried about is the absence of my profile folder in C:\Users. However come to think of, a symlink to my own user profile might solve it, what do you say?
    – Ariane
    Commented Jun 6, 2013 at 15:29
0

I had the same problem and after 2 days moving files back and forth I found two image files causing the event 201:

vonzufahrtsstrasse.jpg
vonZufahrtsstraße.jpg

After that I deleted all my libraries and tested again with two random binary files. I moved them in different libraries and restarted the file history service again and again. By that I wanted to check if file timestamps, content, size or the filename caused the problem and finally I can surely say that it is the filename only:

tesst.bin
teßt.bin

Bug in File History with Eszett

As you can see here tést.bin and test.bin does not cause the problem (German): https://www.maxrev.de/w10-dateiversionsverlauf-funktioniert-nicht-ereignis-201-t366119,start,10.htm#4450797

But maybe there are other special chars that cause this bug?!

You must log in to answer this question.

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