I'm trying to update a Windows 7 NTFS network drive to a Windows 8 NTFS local drive, and the Update keeps finding a lot of files that it thinks it needs to copy over as "Item exists on left side only". But the item does exist on the right side, with the exact same path. If I run the update then I get lots of file permission errors because it can't rename the .tmp into the destination file (as it already exists, obviously).
It doesn't select all files on the drive, so there must be something specific to these files or paths that is causing the problem.
Example:
Source (\\Ben-mainpc\i):
\\Ben-mainpc\i\Music samples\dfh_superior\downloaded stuff\Superior_dfhS_PC_160\ReadMe.rtf
Destination (D:\):
D:\Music samples\dfh_superior\downloaded stuff\Superior_dfhS_PC_160\ReadMe.rtf
Any ideas what is going wrong here? If it matters, I am having to skip the creation of the lock file because it's not possible to write to the root directory of that drive (due to Homegroup restrictions)
Update wrongly thinks target files don't exist, when they do
- Posts: 5
- Joined: 28 Apr 2001
- Posts: 5
- Joined: 28 Apr 2001
Okay, it looks like I found my own answer here - or rather, 2 answers.
1) FreeFileSync doesn't recognise symbolic links on the target. D:\Music samples\dfh_superior\ is a symbolic link to another drive on my machine, so FFS is seeing that directory as empty, trying to copy files into it when they already exist. I will exclude that directory and handle it manually. It would be nice if FFS could handle it correctly but I am sure there are edge cases where it would be easy to do the wrong thing.
2) Some files had leading spaces in the filename on the source, and those are not present on the destination. This is probably because some of the files had been copied over manually, and the Windows copying process appears to strip off leading spaces. Although Windows appears to ignore leading spaces when opening files, they will still appear as separate files to FFS (and other apps, I assume). Maybe a more graceful way of handling this situation would be good. :)
1) FreeFileSync doesn't recognise symbolic links on the target. D:\Music samples\dfh_superior\ is a symbolic link to another drive on my machine, so FFS is seeing that directory as empty, trying to copy files into it when they already exist. I will exclude that directory and handle it manually. It would be nice if FFS could handle it correctly but I am sure there are edge cases where it would be easy to do the wrong thing.
2) Some files had leading spaces in the filename on the source, and those are not present on the destination. This is probably because some of the files had been copied over manually, and the Windows copying process appears to strip off leading spaces. Although Windows appears to ignore leading spaces when opening files, they will still appear as separate files to FFS (and other apps, I assume). Maybe a more graceful way of handling this situation would be good. :)
-
- Site Admin
- Posts: 7280
- Joined: 9 Dec 2007
> 1)
Symlink handling can be configured in FFS comparison settings: The default is to ignore them.
> 2)
Correct, stripping spaces is the behavior of Windows Explorer. Whether this is a good idea is a different story.
Symlink handling can be configured in FFS comparison settings: The default is to ignore them.
> 2)
Correct, stripping spaces is the behavior of Windows Explorer. Whether this is a good idea is a different story.
- Posts: 5
- Joined: 28 Apr 2001
Ah, I hadn't realized there are separate settings for the current sync job. I'll try again with that option enabled, thanks.
