Fab's AutoBackup 7 Pro - a must have tool for techs

This ----V V V V

So if YOU don't bother to image before that N & P or take the time to look at the filesystem for odd folders your clients may have hidden then YOU are problem NOT Fabs Autobackup!
Fabs Autobackup is a lifesaver but it still requires some physical effort on the tech's part!
End thread. This is the answer.
 
Fab's AutoBackup 7 Pro V7.0.4.32753 has just been released.

Change log:

Fixed:
- A fix in the previous release broke the direct transfer feature

Grab it from your orders history's details on the shop's website at https://store.fpnet.fr/account.php?language=en or using the bundled updater tool (click the "Download Fab's AutoBackup 7.X" link within the program and get the updated files).


Note : there is still no default settings or any odd folders support in this update.
 
Fab's AutoBackup 7 Pro V7.0.4.32753 has just been released.

Change log:

Fixed:
- A fix in the previous release broke the direct transfer feature

Grab it from your orders history's details on the shop's website at https://store.fpnet.fr/account.php?language=en or using the bundled updater tool (click the "Download Fab's AutoBackup 7.X" link within the program and get the updated files).


Note : there is still no default settings or any odd folders support in this update.
Hey Fab, regarding libraries, does AutoBackup grab all libraries or only the 'known' libraries, Documents, Music, Pictures, Videos? That is, if I was to create my own library within the Windows libraries system would it get backed up? And if a library has several folders configured on different drives will they all be included?
 
I did not even know that was possible. That will be a pain to include this
I think these things are worth doing. Put it on the list and give it some thought. There will be a bit code refactoring to accommodate many libraries and many paths within each library. The biggest pain will be refactoring the gui for many libraries.
 
I think these things are worth doing. Put it on the list and give it some thought. There will be a bit code refactoring to accommodate many libraries and many paths within each library. The biggest pain will be refactoring the gui for many libraries.
Indeed.
Do you know where the information about libraries is stored in registry? If so, that would save me some Google search time ;)
Edit: This library feature looks like to be gone in Win8/10. So, this is impossible to transfer it from 7 to 10 right?
 
Last edited:
Indeed.
Do you know where the information about libraries is stored in registry? If so, that would save me some Google search time ;)
Edit: This library feature looks like to be gone in Win8/10. So, this is impossible to transfer it from 7 to 10 right?
Not off the top of my head but I'll have a scout around. I found this discussion at MSDN:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd758096(v=vs.85).aspx

It could get messy:
"To access the contents of a library, you must use the Windows Shell API. Functions of the file-system API cannot be used to access library contents because libraries are not file-system objects. If your program uses a custom file browser that is based on the file-system API, it will not be able to browse libraries or access library content."

However it might not be so bad:
"The easiest way for a program to access library content is to use the Shell Library API. If you are working on a program that uses the file-system API, the Shell Library API can return the file-system folders of a library, which minimizes the change to your existing program code."

IShellLibrary *picturesLibrary;

hr = SHLoadLibraryFromKnownFolder(FOLDERID_PicturesLibrary,
STGM_READ,
IID_PPV_ARGS(&picturesLibrary));

// picturesLibrary now points to the user's picture library

IShellItemArray *pictureFolders;

hr = pslLibrary->GetFolders(LFF_FORCEFILESYSTEM, IID_PPV_ARGS(&pictureFolders));

// pictureFolders now contains an array of Shell items that
// represent the folders found in the user's pictures library
 
Not off the top of my head but I'll have a scout around. I found this discussion at MSDN:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd758096(v=vs.85).aspx

It could get messy:
"To access the contents of a library, you must use the Windows Shell API. Functions of the file-system API cannot be used to access library contents because libraries are not file-system objects. If your program uses a custom file browser that is based on the file-system API, it will not be able to browse libraries or access library content."

However it might not be so bad:
"The easiest way for a program to access library content is to use the Shell Library API. If you are working on a program that uses the file-system API, the Shell Library API can return the file-system folders of a library, which minimizes the change to your existing program code."

IShellLibrary *picturesLibrary;

hr = SHLoadLibraryFromKnownFolder(FOLDERID_PicturesLibrary,
STGM_READ,
IID_PPV_ARGS(&picturesLibrary));

// picturesLibrary now points to the user's picture library

IShellItemArray *pictureFolders;

hr = pslLibrary->GetFolders(LFF_FORCEFILESYSTEM, IID_PPV_ARGS(&pictureFolders));

// pictureFolders now contains an array of Shell items that
// represent the folders found in the user's pictures library
That's C++ code from MSDN. I think you're Delphi, yes? I found a discussion with Delphi code here: https://stackoverflow.com/questions/12485427/how-to-read-write-windows-7-library-locations
and here:
http://codeverge.com/embarcadero.delphi.tools/how-to-scan-the-content-of-a-windows/1063163

I note a comment: "SHLoadLibraryFromKnownFolder() is defined wrong in ShlObj.pas!!!"
 
Today, the program uses the registry and get the paths at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Hrmmm. I found that here. It matches what I see on the tree when there's only one path but when I add a path or change the "Save Location", it doesn't match up any more. It retains the old single path and not the changes. Curious. From what I read, the correct approach is the shell API as above.
 
Hrmmm. I found that here. It matches what I see on the tree when there's only one path but when I add a path or change the "Save Location", it doesn't match up any more. It retains the old single path and not the changes. Curious. From what I read, the correct approach is the shell API as above.
Not sure that would follow when running a program with admin credentials while restoring to another user profile
 
Not sure that would follow when running a program with admin credentials while restoring to another user profile
Yeah, it's gunna be messy. To do it properly, you would have to be prepared to recreate the libraries and the multiple locations within those libraries when restoring to another user profile.

What I haven't yet discovered is how to use the Shell API to reference a user profile other than the "current" one.
 
What I haven't yet discovered is how to use the Shell API to reference a user profile other than the "current" one.
This is my first concern here. If this cannot work offline, going further is useless
 
Last edited:
I have started playing with the libray-ms files in the user profile. It looks like they can be transferred from a computer to another and modified using a simple text editor. That will still be a pain since I will have to parse the files, extract all the paths, checking if the extracted path is the default save path or not. Also, this will change a lot the way Fab's AutoBackup works : the registry detection routine will have to be tossed except for Windows XP computers. In fact, I will have to keep both "mechanisms" and try to not make a copy more than once.
It is worth it anyway
 
I have started playing with the libray-ms files in the user profile. It looks like they can be transferred from a computer to another and modified using a simple text editor. That will still be a pain since I will have to parse the files, extract all the paths, checking if the extracted path is the default save path or not. Also, this will change a lot the way Fab's AutoBackup works : the registry detection routine will have to be tossed except for Windows XP computers. In fact, I will have to keep both "mechanisms" and try to not make a copy more than once.
It is worth it anyway
Oh dear, I seem to have generated a lot of work for you :(
 
It looks like to
A question that just appeared somewhere in the cerebral cortex is this: I presume at the moment you back up files from the Library path found in the registry and restore to the Library path found in the registry. The paths don't have to be the same. It doesn't matter. However, in the scenario where the source Library has multiple paths, how would you handle the restore?

1) Would you attempt to recreate the paths and restore to multiple paths so that the original Library configuration is restored? What if the restore target system doesn't have a D: drive (or whatever), ie not possible to recreate a path?

2) Or maybe just restore everything to the new "Save Location"

3) Pop up option dialog, "User libraries have multiple paths. Do you want to recreate the paths or merge into one path?"

I know the idea of popups in the middle of a restore is contentious so maybe something like this. This will attempt to recreate the library paths but if that can't be done then the paths are merged.

rem restore library pseudo code
for each library

for each path in library
if the path is the old save path
change to new save path
else
attempt to create the path
if creation fails

change path to new save path
if path is writable
restore files
next path
next library
 
Maybe Fabs could discover other library folders, and then simply select these folders in the 'Other Folders' feature that's being planned. This would eliminate the potentially difficult process of restoring the custom library configuration itself, treating the other library folders as just 'Other Folders' to help prevent missing the data.

It still hinges on whether the custom library folders can be discovered in offline mode though.
 
Back
Top