Destination Path Issue
Aug 07, 2019
Hi, recently I had to use the "bvckup2-settings.zip" 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.
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:
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.
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.
Aug 21, 2019
It's alright, I'm already using this really simple backup job, which involves no sophistication at all, but I'm wondering if the above issue could be avoided the next time I have to restore it.
Basically, I'm backing up a Firefox's profile folder, so each time I install it on a new system, such "source" profile's folder with get a "partially new" random name, but the remnant path will always remain the same. What I'm wanting to do, is avoid having to manually alter said path in the backup's job settings, each time I use it in a different system.
Let's say I already have it running at "PC1", with this settings:
Everything with some exceptions (default)
So, what if I want to run that same job, but in another PC? I would just restore the Bvckup 2 "settings" file to that new PC, and expect that job works right away. But it won't, since when I install Firefox on that "PC2", it will generate a new profile folder, whose name will be slightly different than the one present in the job's settings I restored. In that new "PC2" installation, the source's folder will be like this:
Then, I will have to modify that job's path, so it points to the actual folder, and just because of that new "\g1he3rq\" part of the folder's name.
Considering the above facts, I thought of it would be very useful if the invariable ".default" part of the profile's path could be used in combination of wildcards. That way, I will just use something like this for the source folder path:
And that way, each time I restore the Bvckup2's "settings" file to a new PC, the job will remain working just fine, since there will always be a source's folder with that almost constant path.
Aug 23, 2019
Since the above one wasn't precisely a kind of "short illustrative example", I will resume it at this:
Being able to use wildcards in source paths, so jobs' have not to be updated manually when these paths change partially.
So, in case of Firefox's profile folders, a "*.default" at the path will always cover whatever value the program assign for each new installation/profile. Usually, there is only one profile folder, but in case there a more than one, maybe some kind of "exclusions" could be implemented as well.
Alex Pankratov :
Aug 23, 2019
It wasn't exceedingly succinct indeed :) but I now understand what you are after.
The underlying issue is that Firefox keeps its configuration in two places, but you are backing up only one. I think the logical solution would be to back up both part of the config.
What you are suggesting is equipping the program with enough flexibility to allow backing up just one piece of the FF's config and then encoding the logic behind the second piece into the backup configuration itself.
From my perspective you are massively overthinking the problem, at least given the context. I absolutely see an appeal of trying to automate the heck out of everything, but in this particular case this would require building up so much scaffolding that it will dwarf the actual problem.
An alternative is to set C:\Users\Administator\ as the source, start with a blank list and then include AppData\Roaming\Mozilla\Firefox\Profiles\ and Application Data\Mozilla\Firefox\.
In terms of adding support for wildcards in the source/destination paths - I can't think of a way of supporting this cleanly. Not can I see many cases when this might be needed. Just consider what happens if there's more than one match. Or when there are none.
Aug 26, 2019
Hi, let's go by parts:
"...The underlying issue is that Firefox keeps its configuration in two places, but you are backing up only one. I think the logical solution would be to back up both part of the config."
I have no problems at all backing up using just one single location ("roaming"), and all the profile's content is saved correctly in that sense. As you may see over here:
Just one path is mentioned, although I do know there exists another profile's related path ("local"), but that one stores cached data and temp files only, so not really important.
"...What you are suggesting is equipping the program with enough flexibility to allow backing up just one piece of the FF's config and then encoding the logic behind the second piece into the backup configuration itself."
Well, it's not about the backup itself, since it works just fine as it is now, but about how to deal with a source's path that might get eventually changed, according to new installations/deployments. In this specific case, Firefox setting up a new random string each time a new profile is created.
"...From my perspective you are massively overthinking the problem, at least given the context. I absolutely see an appeal of trying to automate the heck out of everything, but in this particular case this would require building up so much scaffolding that it will dwarf the actual problem."
Maybe you are right about overthinking it, but I'm more of the "lazy ass" type if you want, i.e., if it can be done by the program itself, why bother the user. And that's kind of a rule of thumb I believe should apply not only for your program, but in general; of course always it's deemed it aims to efficiency purposes and can be properly implemented.
"...An alternative is to set C:\Users\Administator\ as the source, start with a blank list and then include AppData\Roaming\Mozilla\Firefox\Profiles\ and Application Data\Mozilla\Firefox\."
I would simply point to this path as the source:
That will always backup whatever "RANDOM.default" profile folder there is present over there, besides other ones (if there is more than one profile). I use only one profile, and would simply exclude other ones if needed, but the issue isn't about that, but to backup the contents of that folder (without the folder itself), and forgetting about fixing the source's path each time the job is executed in another environment.
"...In terms of adding support for wildcards in the source/destination paths - I can't think of a way of supporting this cleanly. Not can I see many cases when this might be needed. Just consider what happens if there's more than one match. Or when there are none."
In this specific case, something like "%APPDATA%\Mozilla\Firefox\Profiles\*.default" should always match exactly that one and only folder, since there won't be any other folders with a ".default" name at all; and if there are additional profiles, they will have a customized name right after the eight random strings and the spot. In case no matches are found, a kind of "invalid path" caution message should be shown, as it is currently done by the program for wrong or inexistent paths.
As I mentioned before, this is not a critical issue whatsoever, since I can always take some extra seconds to update the source path when needed, but I was just wondering if that could be automated somehow.
Thanks for your insights about the matter.