17 February 2009

Windows cannot copy file ...

[ UPDATE April 2011: the solution / code mentioned at the end of the article can be incorporated with AUTOEXNT so that the script is run on PC startup as ADMINISTRATOR before any login is invoked. Check out my post on AUTOEXNT to get further clarity ]

Windows cannot copy file c:\windows\system32\profiles\student\Local Settings\Temp\Temporary Internet Files\Content.IE5\C1Y7S1IV\!fcHandoff%2CSW2%3A!fc

After running my desktop lockdown solution for the UKZN LABs, I get this bug cropping up every once in a while:

Windows cannot copy file c:\windows\system32\profiles\student\Local Settings\Temp\Temporary Internet Files\Content.IE5\C1Y7S1IV\!fcHandoff%2CSW2%3A!fcHandoff%2CSW3%3A!fcHandoff%26f%3D150550152%26p%3Dmail_candygram%26id%3D1%26cbk%3DfcLoaded%26bg%3Dtransparent%26tgt%3D_blank%26hs%3D2%26en%3Diso-8859-1%2&r=0 to location C:\Documents and Settings\student\Local Settings\Temp\Temporary Internet Files\Content.IE5\C1Y7S1IV\!fcHandoff%2CSW2%3A!fcHandoff%2CSW3%3A!fcHandoff%26f%3D150550152%26p%3Dmail_candygram%26id%3D1%26cbk%3DfcLoaded%26bg%3Dtransparent%26tgt%3D_blank%26hs%3D2%26en%3Diso-8859-1%2&r=0. Possible causes of this error include network problems or insufficient security rights. If this problem persists, contact your network administrator.

DETAIL - The filename or extension is too long.

And then:

Windows cannot log you on because your profile cannot be loaded. Check that you are connected to the network, or that your network is functioning correctly. If this problem persists, contact your network administrator.

DETAIL - The operation completed successfully.

Here are some places that are "helping" me to fix the problem...

UPDATE: This seems to help the problem, but I still get the occasional bug out as I did before... still working on a complete solution.

- this forum works on the Windows Steady State stuff but same principle should apply here. The most interesting solution offered so far is that it's a permissions issue, or a long file name issue (really?? gosh), and the one dude's solution is to set up a script to run on logoff (if it's graceful) or startup (if it's been ungraceful). I'll try the startup solution, but must make a note at this point:

Deleting the temporary user profile in C:\DOCUMENTS AND SETTINGS\ when logged in as Administrator does also remedy the problem, but it means manually intervening. We don't want that with 300 PCs - it's far too time consuming. I've also attempted to avoid this problem by reducing the temp Internet Files capacity to 1MB (minimum), but that didn't fix the problem either.

Another comment: C:\Documents and Settings\student\Local Settings\Temp\Temporary Internet Files\Content.IE5\C1Y7S1IV exists, but there's no corresponding LOCAL SETTINGS folder in c:\windows\system32\profiles\student ...

My solution / code:
rd /s /q "c:\Documents and Settings\student\Local Settings\temp"

I'm thinking of just removing LOCAL SETTINGS completely and seeing if that fixes the problem. Not much grace with this solution, but it works, so we're 3 steps ahead. Of course if there were something as useful as UPHCLEAN for this, it would help :)


oltman said...

lemme get this straight: you are deleting the TEMP folder on the local PC for each user? and this is because a temp file has too many characters in its path? then its fine, carry on. run it as a LOGOFF script so that when users log off they clear up their TEMP files. this is just good practice.

however, do not delete the entire "local settings" folder. any application data is also stored in there.

BrYan (aka Brattex) said...

Close enough; problem is, running it as a LOGOFF script won't fix the power-failures that happen in South Africa, so it needs to be run as a LOGON script to have any significant impact, because it's a rare thing to have a graceful shutdown nowadays. Also, we're using MANDATORY profiles, so deleting the LOCAL SETTINGS folder wouldn't harm our setup, but good advice for others (if there are any "others" reading this blogpost).

Anonymous said...

I know this old...but the immediate fix (wont keep it from happening again, but will get you into your account) is to log in as admin, open steadystate, unlock the profile in question, login to said profile, logout and back in as admin, and relock profile. Problem solved...for now.

BrYan (aka Brattex) said...

This setup wasn't using STEADYSTATE. I haven't seen the same problem crop up with STEADYSTATE though. I've also thought that maybe running a batch script before any logon occurs, as ADMINISTRATOR, could fix the problem (the batch as mentioned in the post) by using AUTOEXNT.