qBittorrent official forums

Hi, I'm a new user and I couldn't find much on this topic.

I wanted to know if it's possible to have qBittorrent seed completed files if the folder name changed or if certain files are renamed.
I believe utorrent was able to do this, and it would be a very convenient feature if it is already there and I overlooked it.

Right click on any folder in the contents and click on Rename.

EDIT I:

Hmmm... this doesn't seem to be working. That's odd (I had never actually bothered using this before).

EDIT II:

The folder appears to have been renamed but after clicking on another torrent and coming back shows that it hasn't. Right clicking to open it in file manager (Explorer in Windows, just after apparently renaming it) gives an I/O error, saying This folder does not exist yet.

I guess this can be considered a bug (since it obviously doesn't work as advertised)?

Only if you have changed the file names using qBitTorrent OR you have edited the meta-data to the reflect the changes before  loading the job, which is not always going to work if you are joining an existing swarm.

Ciao, could you explain what the purpose of Rename is if doesn't work once the job has loaded (I'm obviously missing something here)?

Windows, Linux or Mac? And what version number?

Windows. 3.2.0 alpha (the 64 bit experimental one).

I'm running 3.1.9.2 on Linux, so not really relevant but rename works for me, there are other problems with the way folders are handled.

However;

Right clicking to open it in file manager (Explorer in Windows, just after apparently renaming it) gives an I/O error, saying This folder does not exist yet.

Are you pre-allocating the payload?
Had the folder contents started downloading?
Was the payload in the "completed" location or the "active" location?

[quote="ciaobaby"]
Had the folder contents started downloading?
[/quote]
I tried it with one that had completed (both active and completed), one that was in progress (after your question) and a completely new one whose metadata retrieval had just completed (again, after your question). All of them gave the same result. I also tried it when they were paused. Even ran qB as an administrator. All gave the same result : deselecting and re-selecting the torrent resulted in the Content tab showing the original names (for both folders and files), and attempting to open said files and folders in Explorer returned the I/O error message, This folder does not exist yet.

[quote="ciaobaby"]
Are you pre-allocating the payload?
[/quote]
No. Did yet another attempt on the third (that is, renaming files and folders in a newly added payload just after metadata retrieval) after enabling pre-allocation, and it yielded the same result.

[quote="ciaobaby"]
Was the payload in the "completed" location or the "active" location?
[/quote]
Answered above.

[quote="ciaobaby"]
I'm running 3.1.9.2 on Linux, so not really relevant but rename works for me, there are other problems with the way folders are handled.
[/quote]
The odds of it being a Windows specific problem are increasing by the minute. I don't have access to either a Linux system (which shouldn't be a problem, since you have said that it works just fine) or a Mac (which might be a problem), so I can't test it on either to verify this.

So, the big question, is this a Windows*-specific bug?
*or should Mac be added as well?

Fuck! I just triggered this trying to see what you are talking about. It actually moved the folder somewhere else entirely.
Does your save path contain non-latin characters by any chance?

Here's another one to add to the list, which explains the file duplication,  with the .!qB extension files remain after completion that I reported in Windows. It actually duplicates the renamed folders when the job completes.



As can be seen, the original is "Ted Talks (hd)" which was renamed to "Ted Talks (HD)". The payload started downloading in the 'completed' location WITH the label "TED" already appended and the renamed folder (before completion) and for whatever reason the folder reverted to the ORIGINAL name on completion along with a completed copy of every file in the renamed folder.

Ignore the different numbers comment I realised later that I had done the screen shots while the files were still completing.

(the job is now seeding and both folders remain)

Ver 3.1.9.2 Linux Mint 16.

On Windows this would have resulted in duplicated files in one folder as reported in this thread

[quote="sledgehammer_999"]
Does your save path contain non-latin characters by any chance?
[/quote]
By non-latin, I'm guessing you mean non-English characters (like the Russian language). The save path used the letters A-Z, a-z and digits 0-9, along with spaces. In the second case (checking on a payload that has started downloading), additionally & and + were included (in the original file name, not the modified one).

[quote="ciaobaby"]
On Windows this would have resulted in duplicated files in one folder as reported in this thread
[/quote]
I haven't checked the option to append .!qb to incomplete files. I'll try this and let you know.
UPDATE:
Tried this. Has no effect. The result is the same.

[quote="sledgehammer_999"]
Fuck! I just triggered this trying to see what you are talking about. It actually moved the folder somewhere else entirely.
[/quote]
Judging by your reaction (the strongest I've seen so far), this is a problem. In my case, it did not move the folder anywhere else though. It just, sort of, ignored the command I gave it. As if it was a request.

@Corpse Canopy

Can you try with the stable version? (3.1.9.2) It works on my machine.

Yes. The rename feature partly works on 3.1.9.2.
By this, I mean that another folder is created with the new name, just like on your machine. The original folder is still there, however.

Is this an issue with Qt5, or something else entirely?

Can you test this build? http://builds.shiki.hu/temp/qbittorrent ... _setup.exe

On my machine the renaming works correctly now.

Works fine , with everything except the .unwanted folders in every folder being shifted to the renamed folder.
As a result, the original folder still exists. With the exception of that, all's well!