The support forum

Destination Path Issue

Doequer :

Aug 07, 2019

Hi, recently I had to use the "" file to restore jobs to a new Bvckup2 installation, and although the process itself went fine, there was some weird issue I'm still wondering how could it been possible. Basically, there was a specific job within such file, which does a backup from a Firefox profile folder; this folder has a randomly generated name, which designates a particular user. The thing is, when I restored the settings file and wanted to run the job, there was an error message about an invalid "source" path being used; and that was correct, since the when I installed the Firefox in the new system, it generated a new profile folder, with a new random name. But the weird issue showed up when I went to fix the job's destination path:

The new one should be like this:


That is, just the last part changed.

But to my surprise, the job saved into the settings file had a different destination path, like this:


When I manually restored the profile's content from one of the backup locations, it was saved into a "Firefox-BK" folder, which had all the respective files, but without them being saved into a "RANDOM.default" kind of folder, but all into the "Firefox-BK" folder itself. But when I wanted to run the restored backup job the error message was about the destination path being incorrect, since it lacked the needed profile's folder name. What I'm wondering is why despite having the incomplete path, the job as saved by the settings' file still worked fine?

When I created the backup job back then, the original intention was all the "RANDOM.default" source content was saved into just one backup folder, like this:


And the job somehow kept working fine like that.

But now, after restoring the job through the settings file, I have to modify the source's folder path, in a way the destination path keeps like this:


And despite at first it copied the content to a new folder, I modified it in a way it copies just the folder's content, excluding the folder itself. But I'm still curious about why the settings file had the incomplete source path when it was saved?


Alex Pankratov :

Aug 08, 2019

But to my surprise, the job saved into the settings file had a different destination path

But I'm still curious about why the settings file had the incomplete source path when it was saved?

My guess is that you didn't actually select "b4ju7wmt.default" when picking up the folder using the folder selection window, the one's shown after clicking on Browse. The latter comes from Windows and it's not exactly the pinnacle of the UX design - it expects one to actually descend into a target folder in order for it to become a selection. It happened to me more than once, i.e. I ended up inadvertently selecting the parent of a folder that I was actually aiming for.

Doequer :

Aug 09, 2019

I see, but what I can't still understand is why despite the settings file had the incomplete path, when I had to restore the backup job contents to the new profile folder, it actually wasn't saved into a  randomly named folder but to the main one that I created for the backup; it seems for some reason the backup job kept saving the content correctly anyway.

After updating the job's path, now if I save the settings file, it does include the random folder name in its path.

Now, what if I want to modify the job, in a way it omits the aforementioned randomly named folder, but at the same time, copy all its content? That is, copying all its content into a main folder, like this:


Instead this:


That way, the next time I have to restore such job's settings, I wouldn't need to manually fix its source path again, which will change for sure.

I already tried to exclude said folder by starting with an empty list, adding an exclusion filter that matches "*.default" folder names, and another filter that includes all the rest of files/folders, but it didn't worked.

Alex Pankratov :

Aug 14, 2019

Sorry for the delay replying. I made several passes over your original post, but I can't make a clear picture of what happened. It's rather hard to follow. What I can tell you is that the program's logic in all relevant parts is dead simple. The chance of this being caused by an actual bug are next to zero.

Meaning that it's likely due to a wrong assumption or a human error somewhere along the line, and so isolating it is an exercise in trying to understand what you might've missed, didn't notice, mis-clicked or misinterpreted. As much as I'd like to help, this is not something that I basically have time to do, not in this format.

If you want to have a resolution I need a list of steps to reproduce it.

* Chances are that once you try and reproduce it, you will run straight into the cause, because you will be on the lookout for it. This is exceedingly common, and which is why being able to reproduce the issue is so important.

Doequer :

Aug 20, 2019

Never mind the delay, it's not a big of an issue anyway. I already tried to reproduce it, but the paths are being saved correctly in the "settings" file now, although when the issue happened, I was,'t using the last program's version. Anyway, as you say, maybe it was just a misinterpretation on my part.

But, I'm still wondering about how the issue I mentioned in the last part of my previous message could be addressed? I mean, is there a way of excluding a determined folder, but still copying all of its content? So, get rif of manually modifying variable strings in specific paths.


Alex Pankratov :

Aug 20, 2019

I mean, is there a way of excluding a determined folder, but still copying all of its content?

I don't understand what you are trying to do, sorry. Please give me a very short illustrative example - here's what the source look like and here's what the backup should look like - and I can say if it's possible to do or not.

New topic

Made by Pipemetrics in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms