Data directory recreated in legacy .local/share/data location after being deleted if FileLogger\Path setting still references a path inside it

[FranciscoPombal]

Please provide the following information

qBittorrent version and Operating System

• 152afa7
• Ubuntu 20.04

If on linux, libtorrent-rasterbar and Qt version

• libtorrent 1.2.10
• 5.12.8

What is the problem

After moving the data directory to the new recommended location, it got recreated in the old location on next startup and the warning about using the legacy location showed up again. Changing the path of the FileLogger\Path setting in the config file to the new path fixed the problem.

What is the expected behavior

The files shouldn't be recreated in the legacy location after migrating the files, regardless of the logger file path setting.

Steps to reproduce

1. Start qBittorrent, using the legacy data directory
2. Get warning (in the terminal) recommending moving the directory to the new location
3. Close qBittorrent
4. Move the data directory to the new location.
5. Make sure the config file contains some entry like FileLogger\Path=/home/user/.local/share/data/qBittorrent/logs
6. Start qBittorrent again.
7. Notice that the warning shows up again, and that new files are created in the legacy location.

Extra info(if any)

Manually changing FileLogger\Path=/home/user/.local/share/data/qBittorrent/logs to FileLogger\Path=/home/user/.local/share/qBittorrent/logs fixes the issue, as one would probably expect. Upon the following start up, no files are recreated in the legacy location, the warning doesn't show, and the new location is used.

[glassez]

The files shouldn't be recreated in the legacy location after migrating the files, regardless of the logger file path setting.

Complete bullshit! (sorry)
There is no logic here. If the user provided some setting, why shouldn't qBittorrent follow it?

[FranciscoPombal]

@glassez

Complete bullshit! (sorry)
There is no logic here. If the user provided some setting, why shouldn't qBittorrent follow it?

Perhaps I worded it wrong. What I meant was that the setting should be migrated or reset in some way so as to prevent the recreation of files in the legacy directory. I agree that migrating/changing/resetting settings is not a pleasant problem to have to deal with.

Or perhaps some other creative solution is required - as long as it prevents the recreation of files in the legacy directory.

[glassez]

When we have an explicitly set setting, there is no exact way to determine that the user doesn't actually want it. We can only assume (taking into account the changes made) that if some path from the settings points inside the legacy directory, and the specified object does not exist, but there is a similar object in the new directory, then the user wanted to use the new one. But I wouldn't want to add this logic to the code. The changes were not intended to add any automatic migration, etc.
IMO, the problem is not worth a damn. New users will use the new directory, old users will use the legacy one. If one of the old ones wants to use the new directory, it just needs to perform simple manipulations on the disk and clean/adjust a couple of settings.
@Chocobo1?
If you really want migration then implement it completely. But I dislike it.

[Chocobo1]

New users will use the new directory, old users will use the legacy one.

If this is the case then there is no problem. Perhaps I was being misled as I don't have enough time to examine the code.

[FranciscoPombal]

The thing is, the whole directory structure (GeoDB, BT_backup, etc, folders) is re-created, not just home/user/.local/share/data/qBittorrent/logs. I also don't think any kind of "migration code" is a good idea. It would be fine if only the logs folder were created, not all the rest as well.

[glassez]

The thing is, the whole directory structure (GeoDB, BT_backup, etc, folders) is re-created

Are you sure you use build with #11644 applied?
Can you confirm that whole directory structure is recreated if you start with new/clean profile?

[glassez]

@lbilli, can you confirm or deny this?

[lbilli]

In case qBittorrent.conf contains an explicit
FileLogger\Path=/home/user/.local/share/data/qBittorrent/logs from a legacy installation,
even if the user moves the content of ~/.local/share/data one level up and delete ~/.local/share/data, I think this happens:

• start qBittorrent, which uses the new directory layout
• ~/.local/share/data/qBittorrent/logs is created as per FileLogger\Path directive
• subsequent qBittorrent executions will check for ~/.local/share/data/, which now exists, and all the legacy directory structure will be recreated.

Possible workarounds:

• detect if FileLogger\Path is explicitly set and advise the user to update it
• checking for the existence of something more specific, like ~/.local/share/data/BT_backup
  ...

[glassez]

• checking for the existence of something more specific, like ~/.local/share/data/BT_backup

I think it should work. BT_backup is hardcoded name so there are no corresponding settings that can confuse the logic.

[lbilli]

Another option could be to check first if the new layout already exists, i.e.:

if     '~/.local/share/qBittorrent' exists -> new layout
elseif '~/.local/share/data/qBittorrent' exists -> legacy layout
else   -> new layout

[txtsd]

The log directory should not cause the entire data directory to be recreated, it should only create the log directory. If the recommended directory is found, qbittorrent should just use it regardless of whether another setting wants to create a particular file in the legacy directory.
I filed a bug at #14177 before finding this. It's basically the same. I just didn't know that the FileLogger setting was what was causing it.
How long until this gets patched? It's been over 2 months that it's been reported and it's a trivial fix imo.

[j1warren]

You also might want to reflect this change on https://github.com/qbittorrent/qBittorrent/wiki/Frequently-Asked-Questions#Where_does_qBittorrent_save_its_settings