#Is bvckup 2 good windows#
The one including the accented word triggering the aforementioned title's deletion issue, but all of them shouldn't even exist at all, since I'm using the program in a English language Windows 7. They were these ones:ĭef_filters 0 00000010 00000010 C:\DOCUME~1\Admin\CONFIG~1\Tempĭef_filters 0 00000010 00000010 C:\Documents and Settings\Admin\Configuración local\Datos de programa\Bvckup2\ĭef_filters 0 00000010 00000010 C:\Documents and Settings\All Users\Datos de programa\Bvckup2 I just realized that there were three invalid exclusion paths in some jobs, and that they were included by default each time a new job was created, if rules applied to them. Jun 07, 2017Thanks for the explanation to that weird behavior. Respect the jobs' numbers being showed somewhere within the program's main GUI, as you say it is really not a crucial feature to have, but back then when the jobs' title were gone, it would have been easier to me to identify them right away between all the test jobs within the configuration backup file, without having to necessarily look into each one settings. "C:\Documents and Settings\Admin\Configuración local\Datos de programa\Bvckup2\"Īs you may guess, the accented "o" from the "Configuración" word is the determining "activation" factor for the subsequent "job's title deletion" bug, which will be finally triggered if the "conf.queue_name" parameter gets changed. So, I noted that those two jobs have present exclusion paths like this: Such exclusion rule isn't wrong per se, rather the particular path it adopts when used in non-English systems is the real cause. The root of the problem seems to be an exclusion rule, which is added by default by the program itself, in those jobs were the "Include everything" option is selected. In that situation, the only way of returning the job's titles is through the program itself, since they will be deleted again if that's done via the settings files and they will remain present, provided the value isn't altered again. So, after I modified said value from two of the test jobs, their titles were deleted in the next program's restart. The thing goes like this:Īlthough the test jobs I have are still working fine, some of them have a let's say "latent" bug, which wouldn't be triggered/evidenced insofar as that specific "conf.queue_name" is altered. Jun 06, 2017Well, it took me a few hours since yesterday till a few moments ago, but I finally was able to find the culprit of that weird behavior. This will assign the job to a queue called "Fubar123". In older releases job's queue can be set by adding an override to the job's config: Starting with Release 82 job's queue can be set via: If you want to call one " " (that is 4 spaces), you are welcome to do that. Queue names are case-sensitive, but otherwise there are no restrictions. Queues are identified by their names and they are created by simply adding a job to them. Otherwise they are added to a central queue called "Default" and executed one by one. If enabled, all jobs are executed immediately. Menu > Options > Preferences > Enable Concurrent Backups setting If a job is not assigned to a queue (which is a default case), then its scheduling is controlled by
If we have jobs A and B assigned to queue Q1 and jobs C and D assigned to Q2, and we start them all manually, thenĪ will be run immediately, B will be queued and run once A completesĬ will be run immediately, D will be queued and run once C completes
Queues themselves however are processed in parallel. Jobs on the same queue are always executed one by one on first come, first served basis. Backup jobs can be arranged into queues for scheduling purposes.
0 kommentar(er)
