The support forum

Beta Release 30

Alex Pankratov :

Aug 22, 2013


Tweak how the checks for updates are performed.

In short - the update server now reports not only the latest available version, but also a consolidated list of changes *relative to the installed version*. It also looks at these changes and determines the severity of the update, which can be one of "optional", "normal" and "critical". Both the severity indicator and the change list are now a part of the "Checking for updates" window.

See here for how it looks -
And here for a longer description -

Issues resolved

1. "Launch at log on" not working on W8 when running with full Admin privileges.

This was due to how the app was determining if it's being run as a service. Prior to this release it looked up the name of its parent process, and if it was "services.exe", then it assumed it's being launched as a service. When I reworked "launch at log on" to use Task Scheduler when running as Admin few releases back, I didn't realize that on W8 tasks are launched as child processes of "services.exe". So what happened was that bvckup *was* started at log on, it checked its parent and decided that it needs to run as a service. Naturally failed at that and exited.

I removed this "service auto-detection" code and replaced it with a dumb --service switch that is passed to bvckup2.exe when it is installed as a service.

2. Erroneous job suspension of failing jobs. This was accidentally introduced in BR28, it was a part of some experimental feature that I ended up excluding from the app.

3. Crash when hitting Enter in the "Checking for updates" window when it's in the "nothing new" state.

MikeB :

Aug 23, 2013

A (very) minor cosmetic observation: when a given job is active and copying a file, the bytes left to process in that step are indicated, counting down, on the right of the display. If you start with a large file (1 GB plus, say) then when the remainder drops below 1 GB you get a value with leading zeroes (e.g. 000,932,234,111) which stays around long enough to look slightly untidy. I imagine the same happens when the MB and KB thresholds are reached but these flash past so quickly they barely are noticed; but the GB leading zeroes are there for rather longer.

Would it cost too many CPU cycles to check for the leading zeroes condition and remove them from the display?

MikeB :

Aug 24, 2013

A job I've created to copy about 2.5TB from a NAS to a USB 3.0 PC-attached drive has completed fine apart from showing an Error: Access Denied in the log for updating its tickle file. As far as I can deduce from the time-stamps a tickle file was created when the job was first run yesterday, but it has never been able to be changed on subsequent runs. The host PC is 64b Win 7 Home Premium.

Alex Pankratov :

Aug 24, 2013

@MikeB - Not to sound obtuse, but what is "tickle file"? Generally speaking, any file that is open for exclusive access by some running application is likely to generate this sort of error. In some cases, such application may be Windows itself, so it all really depends what the actual file is.

With regards to the leading zeroes - this was by design, believe it or not. The idea was that regardless of when you are looking at the counter, you can get an immediate idea of how large the file is, where the copying is at and how fast it is going. However, having lived with it since BR1, I now think it wasn't such a great idea. It's basically what you said - it's untidy and looks like an oversight rather than a feature :) I am replacing it a simple % and a total file size in the next release.

MikeB :

Aug 26, 2013

@Alex: 1)  I have emailed you about .tickle files, and

2) if you are re-polishing the dynamic part of the UI anyway, I would find some sort of finish time prediction very helpful (can't speak for others, obviously), perhaps like:

I'm not interested in a prediction to the microsecond, but it would be useful to know if the current job is a cup of coffee or War & Peace. During times when the prog is completely unable to make a sensible prediction, the advisory could be omitted or a boiler plate substituted. Just my tuppence!

Oh, and my preference would be for the prediction to be  stated in terms of my local PC time (so the example tells me it will finish around 09:50 my time, not that 9 hr 50m still remain).

Alex Pankratov :

Aug 26, 2013

@MikeB - I will be adding the ETA, but more likely after the first production release.

The reason being is that it gets rather tricky in a presence of a large number of smaller files. In this case time needed to copy the file is comparable to the time needed to open and close the file, so a simple BYTES/COPYING_SPEED formula breaks down and yields wrong numbers. So instead it needs a linear regression estimator and I won't be able to do it before the release.

V1 had such estimator, but it was only used for estimating the copying speed rather than completion times -

New topic

Made by IO Bureau in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms