Wrong behavior while renaming a folder

deekerman commented

2026-02-21 15:46:06 -05:00

Owner

Originally created by @reyaz006 on GitHub (Aug 20, 2014).

Example: I have a torrent "Funny_Things", finished 100% and seeding atm:

Funny_Things\video1.mp4 - 100mb
Funny_Things\video2.mp4 - 100mb
Funny_Things\video3.mp4 - 100mb
Funny_Things\Photos\photo1.jpg - 100kb
Funny_Things\Photos\photo2.jpg - 100kb
Funny_Things\Photos\photo3.jpg - 100kb

Someone updates the torrent on the source with edited/updated content. "Photos" are updated.

I'm adding that updated torrent, but I just want to check new Photos, while preserving old ones. Thus, I'm not deleting the first torrent from the list. In the New Torrent dialog, I'm renaming the folder manually before starting the new torrent, so it looks like this now:

Funny_Things 2\video1.mp4 [do not download]
Funny_Things 2\video2.mp4 [do not download]
Funny_Things 2\video3.mp4 [do not download]
Funny_Things 2\Photos\photo1.jpg - 200kb
Funny_Things 2\Photos\photo2.jpg - 200kb
Funny_Things 2\Photos\photo3.jpg - 200kb

Next thing that happens, the app moves files from [Funny_Things] to [Funny_Things 2] (!), so now my first torrent contains only

Funny_Things\
Funny_Things\Photos\

Then, after second torrent gets downloaded, here is what I have:

Funny_Things 2\video1.mp4 - 100mb
Funny_Things 2\video2.mp4 - 100mb
Funny_Things 2\video3.mp4 - 100mb
Funny_Things 2\Photos\photo1.jpg - 200kb
Funny_Things 2\Photos\photo2.jpg - 200kb
Funny_Things 2\Photos\photo3.jpg - 200kb

Files from my first torrent got wiped, and now I have files in [Funny_Things 2] that I specifically requested not to download.

That's quite a problem.

Originally created by @reyaz006 on GitHub (Aug 20, 2014). Example: I have a torrent "Funny_Things", finished 100% and seeding atm: <pre>Funny_Things\video1.mp4 - 100mb Funny_Things\video2.mp4 - 100mb Funny_Things\video3.mp4 - 100mb Funny_Things\Photos\photo1.jpg - 100kb Funny_Things\Photos\photo2.jpg - 100kb Funny_Things\Photos\photo3.jpg - 100kb</pre> Someone updates the torrent on the source with edited/updated content. "Photos" are updated. I'm adding that updated torrent, but I just want to check new Photos, while preserving old ones. Thus, I'm not deleting the first torrent from the list. In the New Torrent dialog, I'm renaming the folder manually before starting the new torrent, so it looks like this now: <pre>Funny_Things 2\video1.mp4 [do not download] Funny_Things 2\video2.mp4 [do not download] Funny_Things 2\video3.mp4 [do not download] Funny_Things 2\Photos\photo1.jpg - 200kb Funny_Things 2\Photos\photo2.jpg - 200kb Funny_Things 2\Photos\photo3.jpg - 200kb</pre> Next thing that happens, the app moves files from [Funny_Things] to [Funny_Things 2] (!), so now my first torrent contains only <pre>Funny_Things\ Funny_Things\Photos\</pre> Then, after second torrent gets downloaded, here is what I have: <pre>Funny_Things 2\video1.mp4 - 100mb Funny_Things 2\video2.mp4 - 100mb Funny_Things 2\video3.mp4 - 100mb Funny_Things 2\Photos\photo1.jpg - 200kb Funny_Things 2\Photos\photo2.jpg - 200kb Funny_Things 2\Photos\photo3.jpg - 200kb</pre> Files from my first torrent got wiped, and now I have files in [Funny_Things 2] that I specifically requested not to download. That's quite a problem.

deekerman added the

Feature request

Data loss

labels

2026-02-21 15:46:06 -05:00

deekerman commented

2026-02-21 15:46:08 -05:00

Author

Owner

@chrishirst commented on GitHub (Aug 20, 2014):

Torrent payloads are NOT currently "mutable" in ANY other BT clients than SOME versions of uTorrent and BitTorrent and they HAVE to be created specifically
Read the BEP on mutable payloads - http://www.bittorrent.org/beps/bep_0039.html

If you load an new or updated job over an existing payload it WILL overwrite the data, that's the nature of the protocol.

@chrishirst commented on GitHub (Aug 20, 2014): Torrent payloads are NOT currently "mutable" in ANY other BT clients than SOME versions of uTorrent and BitTorrent and they HAVE to be created specifically Read the BEP on mutable payloads - http://www.bittorrent.org/beps/bep_0039.html If you load an new or updated job over an existing payload it WILL overwrite the data, that's the nature of the protocol.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@reyaz006 commented on GitHub (Aug 20, 2014):

Thanks. If I got you right, this is a basic limitation of the most default protocol implementations. I can understand that.

Am I wrong in presuming that even though this behavior may be correct from this point, it still feels unintuitive and inadequate to regular user?

As a user, I'd like to think that each torrent is a separate entity and the last thing I want is that some new torrent steals the files from different completed jobs. Some kind of explanation or notification before touching things I didn't request to touch could really help.

@reyaz006 commented on GitHub (Aug 20, 2014): Thanks. If I got you right, this is a basic limitation of the most default protocol implementations. I can understand that. Am I wrong in presuming that even though this behavior may be correct from this point, it still feels unintuitive and inadequate to regular user? As a user, I'd like to think that each torrent is a separate entity and the last thing I want is that some new torrent steals the files from different completed jobs. Some kind of explanation or notification before touching things I didn't request to touch could really help.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@chrishirst commented on GitHub (Aug 21, 2014):

It's quite simple really.

The bittorrent protocol does not understand what 'folders' and 'files' are, it simply does not use them. A torrent payload is simply an amount of data that is split into several equally sized blocks called pieces and a piece may contain part of a file, all of a file or more than one file.

http://lifehacker.com/285489/a-beginners-guide-to-bittorrent
https://wiki.theory.org/BitTorrentSpecification
http://qbforums.shiki.hu/index.php/topic,2481

But yes each task is a 'new' task, but if the folder and files names 'clash' BT clients does not know that and simply 'trusts' the information that the underlying disc filing system gives it.

@chrishirst commented on GitHub (Aug 21, 2014): It's quite simple really. The bittorrent protocol does not understand what 'folders' and 'files' are, it simply does not use them. A torrent payload is simply an amount of data that is split into several equally sized blocks called pieces and a piece may contain part of a file, all of a file or more than one file. http://lifehacker.com/285489/a-beginners-guide-to-bittorrent https://wiki.theory.org/BitTorrentSpecification http://qbforums.shiki.hu/index.php/topic,2481 But yes each task is a 'new' task, but if the folder and files names 'clash' BT clients does not know that and simply 'trusts' the information that the underlying disc filing system gives it.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Aug 22, 2014):

one possible workaournd: you remove the first torrent without removing the data files from disk. Then you add the second one and SELECT the already downloaded files too. Then you just wait for the file recheck to finish and the old files should be recognised as 100% complete.

Also this will help in the future when implemented: http://qbforums.shiki.hu/index.php/topic,2294.0.html

@sledgehammer999 commented on GitHub (Aug 22, 2014): one possible workaournd: you remove the first torrent without removing the data files from disk. Then you add the second one and SELECT the already downloaded files too. Then you just wait for the file recheck to finish and the old files should be recognised as 100% complete. Also this will help in the future when implemented: http://qbforums.shiki.hu/index.php/topic,2294.0.html

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@reyaz006 commented on GitHub (Aug 22, 2014):

one possible workaournd

Then I'd need to also move out old files from [Photos] or I'll lose them as soon as I choose Recheck.

if the folder and files names 'clash' BT clients does not know that

There should be a possibility for the client to rely on user-defined filenames before checking with the disk file system, I think.
It allows us to rename anything, afterall. Even though it may not be a part of specification.

@reyaz006 commented on GitHub (Aug 22, 2014): > one possible workaournd Then I'd need to also move out old files from [Photos] or I'll lose them as soon as I choose Recheck. > if the folder and files names 'clash' BT clients does not know that There should be a possibility for the client to rely on user-defined filenames before checking with the disk file system, I think. It allows us to rename anything, afterall. Even though it may not be a part of specification.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Aug 22, 2014):

old files from [Photos]

Not if in the new torrent the same files exist under the same path. If you enable them in the new torrent too they should recheck.

@sledgehammer999 commented on GitHub (Aug 22, 2014): > old files from [Photos] Not if in the new torrent the same files exist under the same path. If you enable them in the new torrent too they should recheck.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@reyaz006 commented on GitHub (Aug 22, 2014):

Sorry but did you read my original comment? I said I wanted to have both versions of those files, old and new. Or are you saying that the client would backup old versions of files somewhere before overwriting them with new files from the new torrent?

I'll try to make it more clear.
Here is what I'm expecting to get after my actions described in my original comment:

Funny_Things\video1.mp4 - 100mb
Funny_Things\video2.mp4 - 100mb
Funny_Things\video3.mp4 - 100mb
Funny_Things\Photos\photo1.jpg - 100kb
Funny_Things\Photos\photo2.jpg - 100kb
Funny_Things\Photos\photo3.jpg - 100kb
Funny_Things 2\Photos\photo1.jpg - 200kb
Funny_Things 2\Photos\photo2.jpg - 200kb
Funny_Things 2\Photos\photo3.jpg - 200kb

Here is what I'm getting instead:

Funny_Things\ - empty
Funny_Things\Photos\ - empty
Funny_Things 2\video1.mp4 - 100mb
Funny_Things 2\video2.mp4 - 100mb
Funny_Things 2\video3.mp4 - 100mb
Funny_Things 2\Photos\photo1.jpg - 200kb
Funny_Things 2\Photos\photo2.jpg - 200kb
Funny_Things 2\Photos\photo3.jpg - 200kb

@reyaz006 commented on GitHub (Aug 22, 2014): Sorry but did you read my original comment? I said I wanted to have both versions of those files, old and new. Or are you saying that the client would backup old versions of files somewhere before overwriting them with new files from the new torrent? I'll try to make it more clear. Here is what I'm expecting to get after my actions described in my original comment: <pre>Funny_Things\video1.mp4 - 100mb Funny_Things\video2.mp4 - 100mb Funny_Things\video3.mp4 - 100mb Funny_Things\Photos\photo1.jpg - 100kb Funny_Things\Photos\photo2.jpg - 100kb Funny_Things\Photos\photo3.jpg - 100kb Funny_Things 2\Photos\photo1.jpg - 200kb Funny_Things 2\Photos\photo2.jpg - 200kb Funny_Things 2\Photos\photo3.jpg - 200kb</pre> Here is what I'm getting instead: <pre>Funny_Things\ - empty Funny_Things\Photos\ - empty Funny_Things 2\video1.mp4 - 100mb Funny_Things 2\video2.mp4 - 100mb Funny_Things 2\video3.mp4 - 100mb Funny_Things 2\Photos\photo1.jpg - 200kb Funny_Things 2\Photos\photo2.jpg - 200kb Funny_Things 2\Photos\photo3.jpg - 200kb</pre>

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Aug 22, 2014):

So you want to have the new torrent in a new/different base folder?

@sledgehammer999 commented on GitHub (Aug 22, 2014): So you want to have the new torrent in a new/different base folder?

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@reyaz006 commented on GitHub (Aug 23, 2014):

Yes, and I also want to keep the old base folder where it was, with its contents. What it's doing instead is moving files from old torrent folder to new chosen folder without asking me. And I've renamed folder inside the content/options dialog, before it could start the torrent.

The fact that it also moves files marked for skipping is not important here, since it should not be the case when the issue is fixed properly.

@reyaz006 commented on GitHub (Aug 23, 2014): Yes, and I also want to keep the old base folder where it was, with its contents. What it's doing instead is moving files from old torrent folder to new chosen folder without asking me. And I've renamed folder inside the content/options dialog, before it could start the torrent. The fact that it also moves files marked for skipping is not important here, since it should not be the case when the issue is fixed properly.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@chrishirst commented on GitHub (Aug 23, 2014):

Sorry but did you read my original comment?

And did you read the bit about that is how the protocol works.

What it's doing instead is moving files from old torrent folder to new chosen folder without asking me

Exactly as it will do, because BitTorrent ISN'T eDonkey or GNutella.

Yes, and I also want to keep the old base folder where it was, with its contents

Then simply rename the original in the client first.

The simple fact is that if you load a job that has changed slightly into the same 'space' as the original, BT clients WILL use whatever blocks of data match the original metadata hashes and replace the ones that don't.

The fact that it also moves files marked for skipping is not important here, since it should not be the case when the issue is fixed properly.

BT Clients use the hash ID to identify what behaviour should be applied to a particular task, the 'new' task has a different ID so whatever was applied to task 'A' will NOT EVER apply to task 'B'.

@chrishirst commented on GitHub (Aug 23, 2014): > Sorry but did you read my original comment? And did you read the bit about that is how the protocol works. > What it's doing instead is moving files from old torrent folder to new chosen folder without asking me Exactly as it will do, because BitTorrent ISN'T eDonkey or GNutella. > Yes, and I also want to keep the old base folder where it was, with its contents Then simply rename the **original** in the client first. The simple fact is that if you load a job that has changed slightly into the same 'space' as the original, BT clients WILL use whatever blocks of data match the original metadata hashes and replace the ones that don't. > The fact that it also moves files marked for skipping is not important here, since it should not be the case when the issue is fixed properly. BT Clients use the hash ID to identify what behaviour should be applied to a particular task, the 'new' task has a different ID so whatever was applied to task 'A' will NOT EVER apply to task 'B'.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Aug 23, 2014):

Then simply rename the original in the client first.

If I understand him correctly, he changes the base folder name of the 2nd torrent in the "Add new torrent" dialog, but qbt instead of creating everything in the new base folder name it moves everything from the old base folder name to the new base folder name.
This bug is exposed in this scenario because the 2 torrents have originally the same base folder name. What I suspect is happening is that qbt instead of taking the new folder name and creating everything under it, it gets the unchanged name and then performs a move/set location to the new name.

@reyaz006 Can you confirm?

@sledgehammer999 commented on GitHub (Aug 23, 2014): > Then simply rename the original in the client first. If I understand him correctly, he changes the base folder name of the 2nd torrent in the "Add new torrent" dialog, but qbt instead of creating everything in the new base folder name it moves everything from the old base folder name to the new base folder name. This bug is exposed in this scenario because the 2 torrents have **originally** the same base folder name. What I suspect is happening is that qbt instead of taking the new folder name and creating everything under it, it gets the **unchanged** name and then performs **a move/set location** to the new name. @reyaz006 Can you confirm?

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@reyaz006 commented on GitHub (Aug 24, 2014):

And did you read the bit about that is how the protocol works.

I've tried to read your links but haven't found much about renaming. I think transfer protocol has little to do with how any client deal with file system and user preferences. I'm talking about files and folders, not data blocks or hashes.

the 'new' task has a different ID so whatever was applied to task 'A' will NOT EVER apply to task 'B'.

Well, in my case the client at least touched files from the old torrent, which hashes were not mentioned in new torrent at all. Namely, it moved

Funny_Things\Photos\photo1.jpg - 100kb
Funny_Things\Photos\photo2.jpg - 100kb
Funny_Things\Photos\photo3.jpg - 100kb

to

Funny_Things 2\Photos\photo1.jpg - 100kb
Funny_Things 2\Photos\photo2.jpg - 100kb
Funny_Things 2\Photos\photo3.jpg - 100kb

then if I let the new torrent dowload, it'll overwrite those with

Funny_Things 2\Photos\photo1.jpg - 200kb
Funny_Things 2\Photos\photo2.jpg - 200kb
Funny_Things 2\Photos\photo3.jpg - 200kb

If I understand him correctly, he changes the base folder name of the 2nd torrent in the "Add new torrent" dialog, but qbt instead of creating everything in the new base folder name it moves everything from the old base folder name to the new base folder name.
This bug is exposed in this scenario because the 2 torrents have originally the same base folder name. What I suspect is happening is that qbt instead of taking the new folder name and creating everything under it, it gets the unchanged name and then performs a move/set location to the new name.

All correct. Your conclusion is the same as mine. It seemed like default behavior for this case is "create under default name, then move into renamed location", and qbt forgot to check if files already exist for a different torrent job. It should be "create under user-defined name from the start".

Also, I can't confirm this for sure, but with some torrents I remember that qbt left empty folders with original names after I've performed a rename operation, also in "Add new torrent" dialog. I think when this happened I thought it may have something to do with unicode characters or big amount of files in the torrent. Not sure if this also involved skipping (do not download) any files. I'll write more details if I encounter that again.

@reyaz006 commented on GitHub (Aug 24, 2014): > And did you read the bit about that is how the protocol works. I've tried to read your links but haven't found much about renaming. I think transfer protocol has little to do with how any client deal with file system and user preferences. I'm talking about files and folders, not data blocks or hashes. > the 'new' task has a different ID so whatever was applied to task 'A' will NOT EVER apply to task 'B'. Well, in my case the client at least touched files from the old torrent, which hashes were not mentioned in new torrent at all. Namely, it moved <pre>Funny_Things\Photos\photo1.jpg - 100kb Funny_Things\Photos\photo2.jpg - 100kb Funny_Things\Photos\photo3.jpg - 100kb</pre> to <pre>Funny_Things 2\Photos\photo1.jpg - 100kb Funny_Things 2\Photos\photo2.jpg - 100kb Funny_Things 2\Photos\photo3.jpg - 100kb</pre> then if I let the new torrent dowload, it'll overwrite those with <pre>Funny_Things 2\Photos\photo1.jpg - 200kb Funny_Things 2\Photos\photo2.jpg - 200kb Funny_Things 2\Photos\photo3.jpg - 200kb</pre> > If I understand him correctly, he changes the base folder name of the 2nd torrent in the "Add new torrent" dialog, but qbt instead of creating everything in the new base folder name it moves everything from the old base folder name to the new base folder name. > This bug is exposed in this scenario because the 2 torrents have originally the same base folder name. What I suspect is happening is that qbt instead of taking the new folder name and creating everything under it, it gets the unchanged name and then performs a move/set location to the new name. All correct. Your conclusion is the same as mine. It seemed like default behavior for this case is "create under default name, then move into renamed location", and qbt forgot to check if files already exist for a different torrent job. It should be "create under user-defined name from the start". Also, I can't confirm this for sure, but with some torrents I remember that qbt left empty folders with original names after I've performed a rename operation, also in "Add new torrent" dialog. I think when this happened I thought it may have something to do with unicode characters or big amount of files in the torrent. Not sure if this also involved skipping (do not download) any files. I'll write more details if I encounter that again.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@chrishirst commented on GitHub (Aug 24, 2014):

I'm talking about files and folders, not data blocks or hashes.

And??? You obviously missed the bit about bittorrent client NOT using folder and files.

The BT protocol is ABSOLUTELY nothing to do with naming or renaming which is why you will find nothing.
File and folder names are defined in the metadata NOT the payload and are passed to the operating system's file manager.

Also, I can't confirm this for sure, but with some torrents I remember that qbt left empty folders with original names after I've performed a rename operation,
Not qBT, but the file manager does. As above BitTorrent clients work with the BINARY DATA that makes up the payload NOT the files and folder names.

@chrishirst commented on GitHub (Aug 24, 2014): > I'm talking about files and folders, not data blocks or hashes. And??? You obviously missed the bit about bittorrent client NOT using folder and files. The BT protocol is ABSOLUTELY nothing to do with naming or renaming which is why you will find nothing. File and folder names are defined in the metadata NOT the payload and are passed to the operating system's file manager. > Also, I can't confirm this for sure, but with some torrents I remember that qbt left empty folders with original names after I've performed a rename operation, > Not qBT, but the file manager does. As above BitTorrent clients work with the BINARY DATA that makes up the payload NOT the files and folder names.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@reyaz006 commented on GitHub (Aug 24, 2014):

Sorry, I'm not getting your point.

Qbt handles metadata too, and you will find plenty of results for "rename" query here in the code. I don't see why qbt can not or should not operate with folders as my previous comment suggested.

@reyaz006 commented on GitHub (Aug 24, 2014): Sorry, I'm not getting your point. Qbt handles metadata too, and you will find plenty of results for "rename" query here in the code. I don't see why qbt can not or should not operate with folders as my previous comment suggested.

deekerman commented

2026-02-21 15:46:10 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Aug 24, 2014):

@chrishirst

The real problem is descripted here:

If I understand him correctly, he changes the base folder name of the 2nd torrent in the "Add new torrent" dialog, but qbt instead of creating everything in the new base folder name it moves everything from the old base folder name to the new base folder name.
This bug is exposed in this scenario because the 2 torrents have originally the same base folder name. What I suspect is happening is that qbt instead of taking the new folder name and creating everything under it, it gets the unchanged name and then performs a move/set location to the new name.

and here:

All correct. Your conclusion is the same as mine. It seemed like default behavior for this case is "create under default name, then move into renamed location", and qbt forgot to check if files already exist for a different torrent job. It should be "create under user-defined name from the start".

Let's not talk about offtopic things.

@sledgehammer999 commented on GitHub (Aug 24, 2014): @chrishirst The real problem is descripted here: > If I understand him correctly, he changes the base folder name of the 2nd torrent in the "Add new torrent" dialog, but qbt instead of creating everything in the new base folder name it moves everything from the old base folder name to the new base folder name. > This bug is exposed in this scenario because the 2 torrents have originally the same base folder name. What I suspect is happening is that qbt instead of taking the new folder name and creating everything under it, it gets the unchanged name and then performs a move/set location to the new name. and here: > All correct. Your conclusion is the same as mine. It seemed like default behavior for this case is "create under default name, then move into renamed location", and qbt forgot to check if files already exist for a different torrent job. It should be "create under user-defined name from the start". Let's not talk about offtopic things.

deekerman commented

2026-02-21 15:46:11 -05:00

Author

Owner

@reyaz006 commented on GitHub (Jan 26, 2015):

I found another renaming bug(s) and it seems related.

Example: I add a torrent "Videos_long" with "Add new torrent" dialog. Its contents are:

Videos_long\video1.mp4
Videos_long\video2.mp4
Videos_long\video3.mp4
Videos_long\Old_videos\video00.mp4
Videos_long\Old_videos\video01.mp4

I rename "Videos_long" to "Videos_long_NEW" to make it download into different folder and uncheck the "Videos_long\Old_videos" folder to skip it. It looks like this now:

[x] Videos_long_NEW\video1.mp4
[x] Videos_long_NEW\video2.mp4
[x] Videos_long_NEW\video3.mp4
[ ] Videos_long_NEW\Old_videos\video00.mp4
[ ] Videos_long_NEW\Old_videos\video01.mp4

I click OK to start downloading.

When it's finished (checked on it several days later), I can see the following files got downloaded:

Videos_long_NEW\video1.mp4
Videos_long_NEW\video2.mp4
Videos_long_NEW\video3.mp4
Videos_long_NEW\Old_videos\video01.mp4

Note 2 things:

"Old_videos" got created and some files inside it got downloaded, even though I asked to skip them. (was not able to verify if those were downloaded fully or sparse)
There are no ".unwanted" folders anywhere.

Furthermore, I can also see these folders got created:

Videos_long\
Videos_long\Old_videos\
Videos_long\Old_videos\.unwanted\

Those are empty folders, under name I asked to not use. Their creation dates are same as on previously mentioned folders.

Here is the last thing:
I went to that torrent's Content view in qbt to make sure I disabled the folder I did not want and renamed the main folder. I did both things correctly. After that I did not mark any files anymore, but maybe expanded/collapsed them to see actual content and compare to what I got on hdd. Strangely enough, after that I could no longer find

Videos_long_NEW\Old_videos\video01.mp4

It was silently moved to

Videos_long_NEW\Old_videos\.unwanted\video01.mp4

I checked its properties - it was a sparse file.

I see that modification date of this folder

Videos_long_NEW\Old_videos\

was changed to that moment few minutes ago. And

Videos_long_NEW\Old_videos\.unwanted\

has creation date of same moment. So it was really created when I was browsing completed torrent in qbt, not when it was started few days ago.

I really think renaming feature needs some work. I never had such issues with ut.

(In my real case, there were 3 subfolders that I unchecked and those included some subfolders with some files of various types too.)

@reyaz006 commented on GitHub (Jan 26, 2015): I found another renaming bug(s) and it seems related. Example: I add a torrent "Videos_long" with "Add new torrent" dialog. Its contents are: <pre>Videos_long\video1.mp4 Videos_long\video2.mp4 Videos_long\video3.mp4 Videos_long\Old_videos\video00.mp4 Videos_long\Old_videos\video01.mp4</pre> I rename "Videos_long" to "Videos_long_NEW" to make it download into different folder and uncheck the "Videos_long\Old_videos" folder to skip it. It looks like this now: <pre>[x] Videos_long_NEW\video1.mp4 [x] Videos_long_NEW\video2.mp4 [x] Videos_long_NEW\video3.mp4 [ ] Videos_long_NEW\Old_videos\video00.mp4 [ ] Videos_long_NEW\Old_videos\video01.mp4</pre> I click OK to start downloading. When it's finished (checked on it several days later), I can see the following files got downloaded: <pre>Videos_long_NEW\video1.mp4 Videos_long_NEW\video2.mp4 Videos_long_NEW\video3.mp4 Videos_long_NEW\Old_videos\video01.mp4</pre> Note 2 things: 1. "Old_videos" got created and some files inside it got downloaded, even though I asked to skip them. (was not able to verify if those were downloaded fully or sparse) 2. There are no ".unwanted" folders anywhere. Furthermore, I can also see these folders got created: <pre>Videos_long\ Videos_long\Old_videos\ Videos_long\Old_videos\.unwanted\</pre> Those are empty folders, under name I asked to not use. Their creation dates are same as on previously mentioned folders. Here is the last thing: I went to that torrent's Content view in qbt to make sure I disabled the folder I did not want and renamed the main folder. I did both things correctly. After that I did not mark any files anymore, but maybe expanded/collapsed them to see actual content and compare to what I got on hdd. Strangely enough, after that I could no longer find <pre>Videos_long_NEW\Old_videos\video01.mp4</pre> It was silently moved to <pre>Videos_long_NEW\Old_videos\.unwanted\video01.mp4</pre> I checked its properties - it was a sparse file. I see that modification date of this folder <pre>Videos_long_NEW\Old_videos\</pre> was changed to that moment few minutes ago. And <pre>Videos_long_NEW\Old_videos\.unwanted\</pre> has creation date of same moment. So it was really created when I was browsing completed torrent in qbt, not when it was started few days ago. I really think renaming feature needs some work. I never had such issues with ut. (In my real case, there were 3 subfolders that I unchecked and those included some subfolders with some files of various types too.)

deekerman commented

2026-02-21 15:46:11 -05:00

Author

Owner

@xavier2k6 commented on GitHub (May 23, 2025):

ANNOUNCEMENT!

For anybody coming across this "Feature Request" & would like/love to see a potential implementation in the future!
Here are some options available to you:

Please select/click the 👍 &/or ❤ reactions in the original/opening post of this ticket.
Please feel free (If you have the "skillset") to create a "Pull Request" implementing what's being requested in this ticket.
(new/existing contributors/developers are always welcome)

DO:

Provide constructive feedback.
Display how other projects implemented same/similar etc.

DO NOT:

Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s).
(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)

@xavier2k6 commented on GitHub (May 23, 2025): ## ANNOUNCEMENT! For anybody coming across this **_"Feature Request"_** & would like/love to see a potential implementation in the future! **Here are some options available to you:** 1. Please select/click the 👍 **&/or** ❤ `reactions` in the original/opening post of this ticket. 2. Please feel free _(If you have the "skillset")_ to create a **_"Pull Request"_** implementing what's being requested in this ticket. **_(new/existing contributors/developers are always welcome)_** ____ **DO:** * Provide constructive feedback. * Display how other projects implemented same/similar etc. **DO NOT:** * Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s). **(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)**

Rows
Columns

Wrong behavior while renaming a folder #1633

ANNOUNCEMENT!