Persistent corruption of Offline Folders cache

[Guest]

I use Offline Folders extensively in Windows XP Professional. I am frequently
plagued with failed synchronisations with the dreaded "The parameter is
incorrect". csccmd /checkdb finds no errors but the cache will not
synchronise one of the four shares that I have in use.

There seems to be little option in these circumstances other than to...

1) Use csccmd /extract to recover all the files I've changed working offline.
2) Reset the offline files cache.
3) Disable Offline Folders, delete the CSC folder, chkdsk the drive (which
usually finds nothing), re-enable Offline Folders.
4) Re-synchronise everything which takes 2-3 hours.

I can't be sure of why this is happening. I have some clues though...

1) Only one share is affected every time.
2) The problem is almost guaranteed to occur if I create a new folder whilst
working offline and then go to synchronise.
3) I recently found that some of my files were not available offline because
their full pathname exceeded 254 characters. They were accessible OK when
online though. Is there a hidden limitation in Offline Folders that restricts
the path length.
4) The troublesome share mentioned in 1) above is the one with the longest
path names, so is there a clue here? Am I creating folders offline whose own
path or the path of files within them are longer than 254 characters, causing
Offline Folders to become corrupt?

Has anyone else seen this? Anyone got any clues as to cure or work round
this problem? It's driving me mad.

Thanks

JB

 

[david.jobin]

I'm experiencing the exact same thing. Actually, I'm experiencing it
right now ... (

I've also found that the culprit is long pathname exceeding 254
characters.

I've no workaround other than the one you proposed ... sooo long !!
......

it is surely a length limitation.
My only solution is to teach users to not create so long pathname
(folders and files names included.)

Sorry to not bring anymore than that. At least you now know that you're
not alone it this exact situation.

have a great day.
David



J Barker a écrit :

 

[Guest]

David,

Good to know I'm not alone. I did some more investigating today and pathname
length is definitely the culprit. This seems to be a bug. Can anyone from
Microsoft comment please?

I've temporarily got round it (I think) by mapping another network drive
further down the folder tree - we'll see. It does need a permanent fix though.

JB