Overlaying locked files

At one point I thought I remember that there was an option to set locked files to be replaced on reboot. This is espeially helpful when you want to overlay your system drive. Did I dream this option? Right now I have Dopus determining what to sync between the system drive and a backup. It's another of these backup products that doesn't quite work right when your restoring your system drive. I'd hate to find that there's no way to sync locked files and find that I've wasted almost 16 hours so far.

Any help or thoughts? If this functionality doesn't exist it should really be added to the sync, queue files and just move, copy in general.

Thanks.

It's still there.

If you choose to replace a file and it is in-use then (possibly after a UAC prompt to see if it was a permissions problem) Opus will tell you it is in use (and might list the programs which are using it) and ask if you want to schedule, retry, cancel, etc. The schedule option schedules the file to be replaced on reboot.

I was glad to hear that. But when I tried a test using a video file that I locked by playing it and then attempting to copy another file overtop I just got the "access denied" message with Retry, Skip, Skip All and Abort. When I tried setting it up as a batch there was not even an option to choose that would copy after a reboot. Am I missing some setting?

I think the problem is the way the movie player has opened the file.

Opus tries to delete the destination file first, if one is in the way. If that deletion fails, you'll be given the option of scheduling the replacement.

The problem is, some movie players open the file in a way which allows the deletion to take place. The deletion succeeds, but the file won't actually go away until the movie player closes it. So the delete succeeds and Opus won't show the schedule option, but then when Opus tries to create the new destination file, the old one is still in the way.

Opening files while allowing them to be deleted is really unusual so it doesn't affect most things, but for some reason some video players (or maybe it's the codecs/splitters; I'm not entirely sure) do this. It causes a few weird things as well as this one.

The compare ended up crashing DO. I don't know if I was trying to do too much with such a big compare in progress or what but in the end it didn't matter. I'll keep the movie file opening in my thoughts in case I come across a similar situation. Although that compare was going on for almost 3 days and I don't know if I'll ever come across a situation like that where I wouldn't want to start over if the "move on boot" didn't process as I expected.

Thanks for looking into it.

If there were so many files that it took 3 days to compare them, the process may have run out of memory or something storing the details of that many things. Or, since we're talking about a huge number of video files, a video codec may have crashed while Opus was querying one of the files for metadata. (Or various other possibilities, of course. Those are just a couple.)

The sync tool in Opus isn't really suited to datasets so massive that they take days to compare.

"The sync tool in Opus isn't really suited to datasets so massive that they take days to compare."

hehe - I figured that out.

As I was attempting to relocate a backup file to another drive, I came up with a file being in use by DO itself and again I did not get the "move on boot" option. I guess I'm questioning if the "move on boot" option may have gotten deactivated or something?

Scheduling moves on reboot is only available when copying from and to local drives.

Re dopus.exe accessing the file, it's possible that it really is. Either Opus itself or a plugin or shell extension that's loaded into the same process may be inspecting the file. (Or may also have triggered a deep antivirus scan of the file, and can't continue until that finishes.)

I've also seen the API which Opus uses to get a list of processes say, incorrectly, that dopus.exe has the file open when it's really something else. I've only seen it happen a couple of times and never when I could debug it to investigate further, but I think there may be false positives with dopus.exe sometimes. (I'm not sure enough to actually filter dopus.exe out of the list, though. Sometimes it really is dopus.exe, and it's useful to know when that is the case.)

This is the first time I've seen this particular error. I was offloading files from a USB drive directly connected to my laptop and putting them onto a network drive. The only other thing that I was doing was generating some hash totals on the copied files because the network drive went full and I wasn't sure if the byte check was totally accurate so I wanted to insure I knew what had truly copied.

Well I guess I'll keep plugin along and one day I'll see that old dialog box again.

Yeah, you can't schedule move-on-reboot to a network drive because the move is done by Windows very early in the boot process, before most of the OS has started and long before any network drives are mounted.