You are very helpful, Radish. Since I am obsessive, I did an extra step and checked the number of source and target files and folders in a test sync and found that 1 - 2 files were missing from the target in each of three folder pairs when looking at the folder properties but that no files were missing when manually counting the files.
Also, a Compare in Filesync showed that the source and target matched perfectly after the sync. I am trying to understand why there are missing files. The folder pairs included a data folder, as well as my favorites and desktop folders.
I should add that in the Favorites folder, there is a Favorites Bar folder. This gets renamed as Links in the target.
My exclude rules were:
Files exclude rules (default)
\System Volume Information\
\$Recycle.Bin\
\RECYCLE?\
*\desktop.ini
*\thumbs.db
I added \.*
Is there an explanation for the missing files in the target folders as noted in the folder properties, whereas Filesynsc shows no missing files and a manual inspection also shows no missing files? Also, is favorites bar supposed to be renamed as Links? Does all of this mean there is something wrong?
Errors
- Posts: 36
- Joined: 17 Jan 2019
-
- Posts: 143
- Joined: 8 Mar 2017
I don't know why you are getting a different file count reported by Windows Explorer Properties. However, you might find the following helpful to troubleshot on your own system: Why does Windows Explorer show a different number of items? That said if you are doing a manual/visual count yourself and things are showing up fine then you would (as the FAQ says) need to troubleshot what the issue is on your own system.
As to your exclude filter:
\.*
I don't understand it. As far as I can see you are telling FFS to filter out all files with no filename and any extension. However, in Windows, as far as I am aware, you can't create a file or folder that doesn't have a filename before the extension (strictly speaking I don't think that for folders a folder with, say, the title test.anything that the ".anything" part of that folder title is regarded as an extension. Put another way I think the concept of having an extension only applies to files, not to folders. I don't know if FFS would regard a folder with that sort of title as having an extension.
In any case, if it was me, I would try removing that exclude filter, run a test compare and sync and see if that has any effect on the file count that Windows Explorer Properties is reporting. (I would guess that you won't see any difference in the file count, and difference, you are reporting as the filter can't actually do anything anyway, at least as far as I think I can understand what it is trying to do.) Remember that, as this is only test, you wouldn't want to save the configuration unless you really do want to preserve the change you made i.e. the removal of that exclude filter for testing purposes.
I have no idea at all why your "Favorites Bar" folder (whatever that is) is being renamed to "Links" at the target.
All above said you are moving into territory that is scraping at the limit of my pay-grade - my use of FFS is very simple so I don't know much about complexities. So maybe someone else might want to chip in if I've got something wrong.
As to your exclude filter:
\.*
I don't understand it. As far as I can see you are telling FFS to filter out all files with no filename and any extension. However, in Windows, as far as I am aware, you can't create a file or folder that doesn't have a filename before the extension (strictly speaking I don't think that for folders a folder with, say, the title test.anything that the ".anything" part of that folder title is regarded as an extension. Put another way I think the concept of having an extension only applies to files, not to folders. I don't know if FFS would regard a folder with that sort of title as having an extension.
In any case, if it was me, I would try removing that exclude filter, run a test compare and sync and see if that has any effect on the file count that Windows Explorer Properties is reporting. (I would guess that you won't see any difference in the file count, and difference, you are reporting as the filter can't actually do anything anyway, at least as far as I think I can understand what it is trying to do.) Remember that, as this is only test, you wouldn't want to save the configuration unless you really do want to preserve the change you made i.e. the removal of that exclude filter for testing purposes.
I have no idea at all why your "Favorites Bar" folder (whatever that is) is being renamed to "Links" at the target.
All above said you are moving into territory that is scraping at the limit of my pay-grade - my use of FFS is very simple so I don't know much about complexities. So maybe someone else might want to chip in if I've got something wrong.
-
- Posts: 143
- Joined: 8 Mar 2017
P.S. I just tested doing a mirror sync on my entire Favorites folder. The source Favorites folder contains the following folders and I have shown the names the folders get at the destination for the backup:
Favorites Bar --> Links
Microsoft Websites --> Microsoft Websites
MSN Websites --> MSN Websites
Websites for United Kingdom --> Links for United Kingdom
Windows Live --> Windows Live
So two folders (highlighted) were renamed to something different at the destination. Kind of scratching my head on this. I then had a look at the exclude filters that were being used for the sync and thought that the Exclude Filter *\desktop.ini might be the culprit. I deleted that filter and OK-ed my way out of the Filters dialogue, did another test sync and the problem with the renames disappeared. Hence, would seem that what name these folders get is in some way dependent on the desktop.ini files being present/absent at the destination. So, it would seem, if you want to avoid this problem you would need to devise a way of including the desktop.ini files for the sync of the Favorites folder, but only for that folder and its subfolders, assuming you don't normally want desktop.ini files included for other folders in you backup configuration. (I'm not sure how this could be done perhaps by setting up a Local Include Filter just for the Favorites folder. Not sure if this can be done but, don't have time to experiment with it just now.
Favorites Bar --> Links
Microsoft Websites --> Microsoft Websites
MSN Websites --> MSN Websites
Websites for United Kingdom --> Links for United Kingdom
Windows Live --> Windows Live
So two folders (highlighted) were renamed to something different at the destination. Kind of scratching my head on this. I then had a look at the exclude filters that were being used for the sync and thought that the Exclude Filter *\desktop.ini might be the culprit. I deleted that filter and OK-ed my way out of the Filters dialogue, did another test sync and the problem with the renames disappeared. Hence, would seem that what name these folders get is in some way dependent on the desktop.ini files being present/absent at the destination. So, it would seem, if you want to avoid this problem you would need to devise a way of including the desktop.ini files for the sync of the Favorites folder, but only for that folder and its subfolders, assuming you don't normally want desktop.ini files included for other folders in you backup configuration. (I'm not sure how this could be done perhaps by setting up a Local Include Filter just for the Favorites folder. Not sure if this can be done but, don't have time to experiment with it just now.
- Posts: 36
- Joined: 17 Jan 2019
The reason for excluding \.* in the filter is that Onedrive creates hidden files starting with “.” and these files cannot be backed up by Free Filesync. Having said that, I have stopped backing up files from Onedrive because I am not sure that Free FileSync can handle these safely.
I assume that the exclude filter may be accounting for some of the source files not being backed up and thus leading to a difference in the file count between the source and target folders as noted in the Windows File Explorer Properties. Also, from your post it looks like excluding *\desktop.ini might account for the files being renamed.
The bottom line question is the following:
Since Compare in Filesync showed that the source and target folders matched perfectly after the sync, and there was a message after the sync that it was completed successfully, can we conclude that the difference in file count between the source and target folders as shown in the File Explorer Properties, as well as the renaming of folders such as the Favorites Bar, is due to the normal functioning of the Exclude Filter and Windows, and that the backup is therefore accurate and reliable and that there is nothing to be concerned about?
I assume that the exclude filter may be accounting for some of the source files not being backed up and thus leading to a difference in the file count between the source and target folders as noted in the Windows File Explorer Properties. Also, from your post it looks like excluding *\desktop.ini might account for the files being renamed.
The bottom line question is the following:
Since Compare in Filesync showed that the source and target folders matched perfectly after the sync, and there was a message after the sync that it was completed successfully, can we conclude that the difference in file count between the source and target folders as shown in the File Explorer Properties, as well as the renaming of folders such as the Favorites Bar, is due to the normal functioning of the Exclude Filter and Windows, and that the backup is therefore accurate and reliable and that there is nothing to be concerned about?
-
- Posts: 143
- Joined: 8 Mar 2017
I'm not sure what to conclude regarding the differences in file count. If you read the FAQs article that I pointed to it could well be the case that Windows is miscounting the files. The article does give some hints as to how you can test this, so you would have to do those tests yourself to help you decide what you can/cannot conclude. As you have done a manual check yourself and, from that check, you say that things actually look okay then I would say from that I would conclude that most likely the issue of the Windows file count is in fact an issue with Windows and has nothing to do with FFS. That said, I would be thinking of ways of testing with FFS if that is the case (and following the suggestions in the FAQs on how to do that). As I'm not at your computer I can't think of and devise some tests -- only you can do that (only you know what you're trying to sync).
If I was you I would make a separate thread asking why FFS is failing to copy over your Onedrive files that start with a dot "." character. That to me does sound like a problem with FFS, maybe even a bug.
(Incidentally, I did find a way of creating files and folders that do start with no filename but do have an 'extension' so it is possible to do this in Windows by using not normal/routine means. For example, I created a folder ".test" and a file ".testfile". I then made them hidden and did a test sync that would include them in the list of files/folders to copy. FFS did copy them without problems. Hence, the result that you are getting with Onedrive files does sound suspicious to me.)
If I was you I would make a separate thread asking why FFS is failing to copy over your Onedrive files that start with a dot "." character. That to me does sound like a problem with FFS, maybe even a bug.
(Incidentally, I did find a way of creating files and folders that do start with no filename but do have an 'extension' so it is possible to do this in Windows by using not normal/routine means. For example, I created a folder ".test" and a file ".testfile". I then made them hidden and did a test sync that would include them in the list of files/folders to copy. FFS did copy them without problems. Hence, the result that you are getting with Onedrive files does sound suspicious to me.)
