BlueBlock

The idea would be for the pre-existing backups in a single-directory will continue to be single-directory as it may be costly to rearrange large backups on remote destinations. I'm of...

I have the local file backend and Mega.nz now using sub-folders. While also handling pre-existing backups without subfolders which will continue to not use subfolders. It will take a bit...

Some backends might mean more API calls but for example the Mega API provides just 1 call which gets a complete list of -all- your files. So in this case...

> * The most important one is the number of subfolders. In your approach, all backups, including larger ones, will result in an extensive list of (sub)folders containing one or...

The good news is it I think my solution provides a lot of flexibility where the method of placing the files can be adjusted easily and does not impact the...

There are backends that support listing files only at each directory level. So walking that structure would be inefficient with sparsely populated directories. I agree we should fill directories. So...

I now have the logic in place to fill folders in a flat manner. For example, with 2000 files per folder and 1000 folders per folder. The first 2000 files...

I need to touch each type of destination to enable them to handle the sub-folders. Edit: moved the list of backends to the PR

> I would recommend to prioritize backends that have a limit to the number of files per folder, like MS OneDrive, SharePoint and Box.com. Good point. Thanks.

For anyone.. when a backend folder does not exist, why ask the user if they want it created during "test"? Why not just create the folder if it does not...