Are there bugs with the latest beta(s) of 10.5.2 regarding SYNC?
When I sync hard disk A to B no files or folders on the destination will be deleted although selected and marked for delete after compare.
Folders and files will be copied (which should be).
The delete process only says there should be e.g. 2367 files be deleted - but finally nothing happens.
When I go into one of the "deepest" folder (on both drives) and only sync the folder where files should be deleted - it works. But when I am more "outside" - e.g. a directory part above or in the root of the drive - no files will be deleted in sub folders.
All files which should be deleted (because they don't exist on the source disk anymore) have been copied with DO on the same machine (home PC).
Previously all has worked. Yesterday I noticed that I have so many files to delete although that shouldn't be - because no sync process on the previous days/weeks has deleted any file on the destination.
The files are music files - after moving from the "check-in" folder to the final folder the sync should make a 1:1 backup on the destination.
I've just tried DO 10.5.2.0 on my Windows 8 x64 notebook with both external hard disk and the same problem as on my Windows 7 x64 machine.
No files will be deleted during the sync process. All settings are correct and I'm the owner of all files and folder on both hard discs.
On the destination hard disk in the root a temporary folder (e.g. "a56715cbdfcebc54c4b1044f1d08") will be created and not deleted anymore. Owner is NT AUTHORITY\SYSTEM.
Does configuring Opus not to use the recycle bin make a difference?
The root folder being created by a system process, if it's really tied to the operation and not coincidental, must be coming from something quite low level, such as the OS itself or antivirus or something. My guess in this case is that something is wrong with the recycle bin on that drive and the OS is trying to repair it but failing. Maybe the permissions are wrong at the root level or inside the hidden recycle bin folder, or the recycle bin data is corrupt. (Can happen, esp. with drives moved between machines.)
But how was it possible to create it with DO? I have also copied / synced the full path from source to destination!
The full path and file name of the destination is e.g. 266 characters.
From the 2300 files to delete I have a lot of shorter full path + file names than 256 chars so it seems to me that if one delete would not work no file will be deleted?
Why do I get the error message only when I unselected "Synchronize sub-folder contents" and not when selected?
Both those errors are coming from Windows itself, rather than Opus. Opus can delete files with very long paths, but Windows cannot send them to the recycle bin (at least currently; it may be updated to work better in the future, but that's up to Microsoft).
The temporary workaround is to avoid using the recycle bin.
The long-term solution is to avoid such long paths entirely as they will cause problems with parts of Windows itself as well as many apps. Parts of the Windows API, as well as third-party libraries and applications, will start to fail with paths longer than 256 characters. (This includes certain functionality within Opus, since it relies on some of those APIs and libraries, although we aim to make the essential parts of Opus handle extremely long paths, so that they can at least be worked on and reorganised.)
I've disabled the recycle bin and now the delete part has worked!
Thanks a lot!
Maybe a workaround until MS has implemented a longer file path name in a future Windows version (e.g. "permanently delete if file path name to long for recycle bin" as option and/ or question) might be helpful.
However - I'll try to reduce the path structure - because a permanently delete permanently on ... I went to often into troubles.
if there is only ONE longer full path + file name (>= 256 characters or so) from all files marked to delete to the recycle bin inside the sync - nothing happens - no files will be deleted (although all others are shorter!) and no error message that a file couldn't be deleted.
I just had to sync-delete 301 files from the destination, but 7 files had a longer path + name - so nothing happened (delete to recycle bin enabled) with all 301 files.
I left the sync and tried to manually delete a long file. The recycle bin error above came up.
I changed DO not to use the recycle bin (SHIFT + DEL for permanently delete did also not work!) and then I deleted these 7 long files.
I changed DO back to recycle bin - did the sync-delete and all other files have been deleted.
Right, but the problem is in Windows and also seems difficult to detect.
Explorer does the same thing, if you just try to delete a folder with a long enough name.
The Recycle Bin API is supposed to, and sometimes does, detect if the names are too long and ask you if you wish to delete the files outright instead. But sometimes it simply fails to do anything, whether it's Opus or Explorer asking it to.
I spent half an hour testing various things and it may require that an individual folder name (not full path) is 260 characters to trigger the bug in Windows, but that is just a guess. It does not seem to happen when the combined folder path is really long but the individual folder names which make up the path are not quite long enough in isolation.
So, if the Recycle Bin is enabled then Opus just passes the list of things to delete to the Windows shell's Recycle Bin API (the same as Explorer). That API is supposed to check if the names are too long and handle things accordingly if they are. But in some cases it just flat-out fails to do anything instead. It's a bug in Windows, and happens in Explorer without Opus's involvement. Avoiding excessively long folder names or disabling the recycle bin are two possible workarounds.
Hi Leo,
Happy Holidays. Are there plans to fix the delete functionality within Sync so that it works even if "use the recycle bin" is turned on?
thanks
It's not really something we can fix, as the bug is in Windows and the API returns success even when it fails.
We added functionality to the Duplicate Finder panel to make it easy to perform a delete without using the Recycle Bin, and without having to change Preferences settings back & forth. I think that is the best we can really do, until/unless Microsoft fix Windows itself.
The fault is in the Recycle Bin, so the only workaround we know of is to not use the Recycle Bin if you're running into problems and can't avoid having the longer names which trigger the Windows bugs. (Newer versions of Windows 10 may also be better, since Microsoft claim to have added a toggle to turn on support for very long paths, but I am not sure if those changes affect the Recycle Bin.)