The support forum

Device Tracking doesn't pause back up schedule

Division :

Aug 07, 2016

Hi guys,

I have an issue with device tracking not pausing the back up job when my ext. HDD is not connected to my computer.

I am using the external drive as my source, backing up to an internal drive in my laptop. The source disk is pinned using device fingerprint for device tracking.

Setting the back up job to run continuously does pause the job when the drive is not present. However, I can't use it this way as I am unable to cleanly eject the drive, even if the back up is up to date.  (I need to be ejecting this drive, and yanking the cable reeks of data corruption to me..)

So i set it on a 10 second schedule instead, this lets me eject the drive cleanly whilst keeping the back up as up to date as possible. But the issue here is - device tracking doesn't pause the back up job whilst the drive is ejected. This results in tonnes of errors and failed runs in the logs.

In both scenarios the job runs when the device is plugged back in and, on the 10 second schedule, ejects without issue, so this isn't a deal breaker for me, I had just assumed device tracking should pause the job, regardless of schedule?

I was surprised not to find something about this in the forums already as I assumed ejecting drives would be fairly common for laptop users. However my guess is that this has come up for me because i have the source/destination on its head and has something to do with how bvckup2 scans the source? Anyway, I would have thought the device tracking would 'rule all' so I'm posting this in case i've found a bug, there's a problem with my install or there's a best practice for setting up the back up job in this scenario.

thanks in advance :)

Alex Pankratov :

Aug 09, 2016

Monitoring source location for changes creates a open reference to that location (and through that to the device itself). So when you are trying to eject the drive, Windows simply sees that there *is* someone actively using this device and fails the eject.

Whether it's the most *natural* way for Windows to handle this situation is debatable, but that's how it works.

What we can do is to add an option of stopping the monitoring when the app get an "eject inquiry" from Windows. There are some caveats to doing this, including, for example, the case when the ejection is aborted by some other app. But I think for the vast majority of cases this should prove to be a good alternative.

Let me see what we can do before the next release, and let's go from there.

Alex Pankratov :

Aug 10, 2016

Should be resolved with 76.4 -

Division :

Oct 24, 2016

Thanks Alex! :)

New topic

Made by IO Bureau in Switzerland

Updates Newsletter
Blog & RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms