[BUG] Contents of directories are not merged if one with such name exists

[nvllz]

Describe the bug Amarok doesn't rename catalogs to their original names if catalogs with those names already exist. Didn't try if the same thing happens when hiding.

To reproduce The easiest way to reproduce such a result is to deal with a nested Screenshots catalog.

1. Hide your Screenshots catalog with Amarok, in my case it's under DCIM/Screenshots, so I hide the whole contents of DCIM. All the catalogs and folders will be renamed to respective hidden names
2. Take a random screenshot. A new DCIM/Screenshots catalog with our screenshot will automatically appear next to our original hidden catalog
3. Unhide the original directory in Amarok
4. Go to the DCIM directory in your file manager. You will see both Screenshots and the hidden catalog in Amarok. Our files have been unhidden, but they are still in a catalog with a hidden name

Expected behavior I believe that Amarok encounters an error when trying to rename a catalog, but there is already one with the exact same name. The expected behavior is for Amarok to merge the two directories. It should check if such a catalog exists before trying to rename it, and if it does, move the processed files to the desired directory and delete the empty one.

[deltazefiro]

@nvllz :clap: Thanks for the report.

My concern: If we merge the folders, what should we do if both the folders contain a file that has the same name? We can just skip the duplicated ones and merge the rest — however that may cause confusion:

An example: Many users use Amarok to hide visual novel game data. If a user starts the launcher by accident when data is still in the hidden state, the launcher is expected to produce lots of configs or log files. These files have the same name as the hidden ones. And merging them could lead to game data corruption which is hard to fix. If we just leave the merge task to the user, the user can simply delete the newly generated folder.

And my solution to your problem: set all the inner nested folders (like DCIM/Screenshots) rather than the outmost one (DCIM) to hide. Amarok doesn't apply obfuscation to the folder directly set to hide, it just hides the folder contents. Yeah that may have several drawbacks, but that's better than the data corruption.

[nvllz]

An example: Many users use Amarok to hide visual novel game data. If a user starts the launcher by accident when data is still in the hidden state, the launcher is expected to produce lots of configs or log files. These files have the same name as the hidden ones. And merging them could lead to game data corruption which is hard to fix. If we just leave the merge task to the user, the user can simply delete the newly generated folder.

The only solution I can think of is to first check for any files before processing if there is already a catalog with the same name, and if there are any files there, let the user decide whether to merge or skip processing for that catalog. If it's too complex, If it's too complex, I can stick to what you said below, but the hiding of the folder name is one thing that I would like to achieve here.

[deltazefiro]

let the user decide whether to merge or skip processing for that catalog

That's where the problem is. The hiding process is performed in a background thread (so it can be triggered by the QuickSettings switch or the PanicButton). Popping out a dialog from background service is generally discouraged by Android and has lots of limitations. Instead, I can try sending a notification to notify the user about the failure & provide a button to auto-merge the folders — no guarantee, I'll have a try later.