Syncronize not deleting files on destination side

Syncronize is not deleting the files on the destination drive. It is copying the files over fine, but is not deleting the files on the destination. I have used this feature every day for the past ca. 5 years and never had a problem until today - soon after upgrading to 10.2.0.0.

I checked the settings in the synchronization box and they are see correctly. See the attached image.

How do I fix this?

Directory Opus Pro 10.2.0.0 (4645) x86
OS 6.1 (B:7601 P:2 T:1) SP 1.0 "Service Pack 1"

Please show us what the whole window looks like after pushing the Compare button, without pushing the Synchronize button. (Including the file displays so we can see what Opus is proposing to do.)

(It might make sense to turn off Hide unaffected files so we can see which files Opus is ignoring, too.)

If there's anything sensitive in the directory, you can use a couple of test directories with dummy files, if you want. (Assuming the problem isn't somehow tied to what's in the folder.)

You don't need to perform the actual sync, just the comparison so we can see if Opus wants to delete any files. (If it wants to delete the files after the Compare, but there turns out to be a separate issue preventing it from actually doing so during the Synchronize, we can then look into that. But first let's concentrate on what the Compare is doing.)

I had to hide the unaffected files or you would not see the ones to be deleted. I sync thousands of files.

When I press Synchronize nothing happens. No delete box opens, and no files are deleted. I have tried this repeatedly. I have rebooted the computer and tried again. I discnnecgted the external drive during the reboot. - All to no effect. Files are copied over, but no files on the destination are deleted.


Here is the result after pressing the Synchronize button. DrOpus knows it did not delete the files.


Can you delete files from that folder normally?

Yes.

If you access the right-hand folder as its (I presume) real location: C:\Users\kirchoff\My Documents\Word Files\Serivce

(Instead of the junction that exists for Window XP compatibility: C:\Documents and Settings\kirchoff\My Documents\Word Files\Serivce)

Does that make any difference?

Yes. It works now. But I do not understand what happened.

Also, I went back to 10.04 to see if it was a problem with 10.2. It is not. I had the same problem with 10.-4 - BUT I never had this problem with 10.04 in the past, and I used that version for some time and never had a problem.

So what is going on here? You fix worked with 10.04 so I assume that it will work with 10.2.

What should I be doing to get Sync working every time again?

Glad that workaround worked, thanks for checking/confirming.

We'll need to look in more detail but I suspect what's happening is due to the C:\Documents and Settings junction being permissioned to deny access to things that look directly below it. The sync tool may be recursing each level of the hierarchy when trying to delete the files, and failing at that point. (There's also some protection in the sync tool itself to avoid certain types of junctions which can cause infinite loops, so it may be something to do with that as well. Not certain yet.)

As long as you use the real path and avoid the XP-compatibility junction, it should continue to work.

I will reset my default lister to avoid Documents and Settings and let you know if any other problems occur.

I do not know why this problem started in the first place, as I have used the same default lister for some years now. When I update I keep the same default lister configuration. I am not sure how it would have gotten switched to the XP-compatability junction.

FWIW, I've just tried reproducing this and the sync is able to delete the files okay for me, even when the target is accessed via the C:\Documents and Settings junction.

I wonder if something may have changed on your system, either the folder permissions of the locations of one of the folders involved (e.g. the My Documents folder being moved somewhere else?), which may have coincided with when it stopped working for you?

I know that someone else here (and others, non-Opus users, we found on the web when hunting down his problem) had a different problem which turned out to be caused by something (it was never clear what) changing the junction's permissions from their defaults.

Nothing has been moved. My computer has been off for about 6 days as it was a holiday here. This problem started when I turned it back on.

How do I check the permissions of the junction? I cannot even get back to the junction now that I have moved off of it and reset my default lister.

A quick way to check the permissions is to use the "icacls" command that's built into Windows.

If you open a Command Prompt and run this:

icacls "C:\Documents and Settings" /L

It should display this:

C:\Documents and Settings Everyone:(DENY)(S,RD) Everyone:(RX) NT AUTHORITY\SYSTEM:(F) BUILTIN\Administrators:(F)

For what it's worth, the other person found a tool which solved the problem for them. I can't vouch for the tool myself as I don't know exactly what it does, and it may be that your problem isn't the same as his (the symptoms are certainly different; he had problems with the Find tool rather than Synchronize), but here's the thread/post if you are interested in investigating it: System drive slow search-keeps looking in Application Data

I'd say it probably isn't worth messing around with, unless you run into other problems that seem related. The root cause may be something else, as I'm only really guessing, and messing around with things to fix a problem that seems to be solved by using the C:\Users folder instead is more likely to cause something else to go wrong than fix anything.

Does the attached tell you anything? I am not sure how to interpret it.

That looks correct, so whatever it is it's probably not the permissions. (Unless there's something that icacls isn't showing, I guess.)