Here is how the sausage is made:
http://technet.microsoft.com/en-us/library/cc787939(WS.10).aspx
If you can figure out from that the end case where the source folder permissions matter one little itty bit but did not on the SP2 version of a dll, you are a better reader than I am! I did not read the "if the permissions are not correct, then fail outright" which changed from SP2 to SP3 versions of fdeploy.dll!
For a better fix, go down to the bottom!
Looks like XP SP3 might break folder redirection. The newer version
of fdeploy.dll in SP3 breaks folder redirection in some cases. Simply
replacing it with the SP2 version makes the client work.
Stolen from the article on msfn.org: If you replace the current %system32%\fdeploy.dll (version 5.1.2600.5512) in SP3 with the one included in SP2 (version 5.1.2600.2180),
Ugh!
Looks like the fix is missing folders?
http://www.msfn.org/board/Folder-Redirection-Broken-in-SP3-t117070.html&p=769637#entry769637
I suppose missing one of the folders that could be redirected could make it break, but why would one write software that poorly? I mean, can't they "-f" test for existence of a folder and move on if it is missing?
Looks like you can "fix" it via group policy: "Uncheck the "Move the contents of My Documents to the new location" option in the GPO (which is enabled by default on a new GPO). Once the GPO change has replicated to all sites, have the client logout and log back in and verify the results."
create the missing directories (Desktop, My Documents, or any other folder that has been re-directed... etc in the profile)... Here is the link I stole the info from: http://www.msfn.org/board/Folder-Redirection-Broken-in-SP3-t117070.html&st=20&p=777468#entry777468
Of course, it could be this hotfix.... Argh! http://support.microsoft.com/kb/892227
Ok, so now I know a bit more!
So it seems the SP3 fdeploy.dll checks to make sure the user has permissions to the source folder, and if the user has a mandatory profile that does not grant them permission for them on the "My Documents" folder on the local machine will cause the fdeploy.dll to fail at the point of checking perms on the local. SP2 had the ability to continue on error and it seems the coders now feel failing without providing errors in logs outside the local machine are appropriate for a failure to hundreds of users (ha).
One thought for fixes for this is: Set the group policy that enforces the redirection on the failing folder to not copy over files from the source. This is usually a hack in the default domain policy.
I.E: Group Policy Editor -> Specific GP -> user Configuration -> Windows Settings -> Folder Redirection -> My Documents -> Properties -> Settings
and un-check the "Move the contents of My Documents to the new location