Hello again! Interesting scenario, for which I think I have a workaround, but
would like some advice or alternatives if they exist.
Consider the following simplified scenario:
XP system, we sync %csidl_MyDocuments% to
\\backupserver\share\%username%\Documents
This would by default include the directories "My Music" and "My Pictures"
for example.
Windows 7 system, using the same sync setup, %csidl_MyDocuments% to
\\backupserver\share\%username%\Documents
In this scenario, the Windows 7 system will try to pull down
\\backupserver\share\%username%\Documents\My Music to
c:\users\%username%\Documents\My Music, but this fails because of permissions
for that junction (at least I believe it's a junction or shortcut) and FFS
just reports a lot of failures because it cannot create or overwrite the
existing file.
Is the simple solution here to turn on "follow" for symbolic links? We have it
off now for some reason, but this might be the simple fix.
The complication is that, for Windows 7 systems, we have also added explict
folder pairs for c:\users\%username%\Music and c:\users\%username%\Pictures,
so if we turn on the "follow" symbolic link option for the Documents root, are
we going to get into a weird conflict condition because the Document folder
pair would already take care of Music and Pictures on Windows 7 because we
enabled "follow" for the symbolic links? If so, perhaps just by enabling the
"follow" option, we would get the "My Music" and the "My Pictures" under
Windows 7 (because of the "follow" option).
Sorry if this is complicated, but ask questions and I will try to answer as
completely as I can. What we are trying to avoid is having to add exclusions
like "\My Music\" or "\My Pictures\" to the Documents folder pair. That raises
local language issues, and because exclusions are relative to the folder
root, we could not for example use %csidl_MyPictures% as an exclusion.
Using %csidl_% macros in exlude filters
- Posts: 74
- Joined: 17 Mar 2008
- Posts: 74
- Joined: 17 Mar 2008
Did some simple initial testing with "follow" on for symlinks - permissions
errors navigating into those folders. Those go away if I were to run FFS as
admin, but that's not an option really. Secondly, it looks like it would
create a folder called \My Pictures on the target share, because the local
junction gets translated to a regular target directory.
SO...
Assuming there is no fix in the works to allow us to use %csidl_MyPictures%,
for example, as a valid folder exclusion, I will have to update our folder
pairs to exclude "\My Music\" and "\My Pictures\" from the My Documents folder
pair and then do separate syncs for them further on in our ffs_batch file. My
concern in this case would be impact on systems running Windows in languages
other than English.
Any option to use your macros in the exclusion list as well, even though they
are full paths?
Typo in Help File the macro %csidl_Pictures% is incorrect, it should be %csidl_MyPictures%
errors navigating into those folders. Those go away if I were to run FFS as
admin, but that's not an option really. Secondly, it looks like it would
create a folder called \My Pictures on the target share, because the local
junction gets translated to a regular target directory.
SO...
Assuming there is no fix in the works to allow us to use %csidl_MyPictures%,
for example, as a valid folder exclusion, I will have to update our folder
pairs to exclude "\My Music\" and "\My Pictures\" from the My Documents folder
pair and then do separate syncs for them further on in our ffs_batch file. My
concern in this case would be impact on systems running Windows in languages
other than English.
Any option to use your macros in the exclusion list as well, even though they
are full paths?
Typo in Help File the macro %csidl_Pictures% is incorrect, it should be %csidl_MyPictures%
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> Is the simple solution here to turn on "follow" for symbolic links? We have
it off now for some reason, but this might be the simple fix.
The solution is to "exclude" symlinks and thereby junktions also. Your
scenario was the main reason to have "exclude" as third symlink option and
also as default. The sole purpose of these symlinks is backwards-compatibility
for Windows-XP applications that are not aware of the new Vista naming
conventions. It's therefore no loss of information if these junctions are not
backed up.
> Typo in Help File
This seems to be correct in the current help file (v5.8)
it off now for some reason, but this might be the simple fix.
The solution is to "exclude" symlinks and thereby junktions also. Your
scenario was the main reason to have "exclude" as third symlink option and
also as default. The sole purpose of these symlinks is backwards-compatibility
for Windows-XP applications that are not aware of the new Vista naming
conventions. It's therefore no loss of information if these junctions are not
backed up.
> Typo in Help File
This seems to be correct in the current help file (v5.8)