Renaming a folder with a locked file causes irreversible folder split

[keseph]

If you attempt to rename a folder inside of a torrent's content structure while one of those files is locked (ex. by a background file system backup service like CrashPlan), then all of the unlocked files will be moved and the locked file will not. In the Content UI, the files will now be split across two separate folders where they were once in a single folder. If you break the lock and attempt to rename the left-behind file's folder to the intended destination, qbittorrent refuses as there is already a folder with that name -- you are left unable to merge the split folders back together short of removing the torrent's metadata, re-adding it, and rechecking the files.
When this affected me, there were no log entries created.
The initial folder split behavior is probably the most reasonable answer absent exclusive-locking every single file to-be-moved before beginning any moves, and could only stand to be improved by a "failed to move file in folder of torrent " message in the log. The recovery behavior could be greatly improved: when renaming a folder and detecting an existing folder with the same name, if that destination folder is also part of this current torrent, then the folder rename should proceed to a filename collision check and then be allowed. This would enable a user to merge together any split folders in a graceful manner.

[chrishirst]

If you attempt to rename a folder inside of a torrent's content structure

Of course it 'breaks' everything, qbittorrent/libtorrent does NOT 'know' that the data has been changed, it just 'knows' that the 'file' is NOT where it is supposed to be and is therefore "missing".

[chrishirst]

Oh, and there is no 'fix' that can be applied in qbittorrent/libtorrent.

[keseph]

I totally agree that an external program renaming one of the active folders wouldn't be addressable inside of qbittorrent, but qbittorrent has a Rename function inside of the Content UI, and that function was what I was referring to in the original description. As the FAQ says, a picture is worth a thousand words, so here're ten of them:

01-initial_content.png: An example torrent with 1 sub-folder named "folder 1" and two files "a.txt" and "b.txt", as shown by qbittorrent's Content pane. The two text files simply have "foo" and "bar" in them, respectively.

02-ls.png: ls -recurse output in powershell showing the same.

03-lock.png: Taking a read-compatible file lock on b.txt

04-blocked_write.png: Open b.txt in notepad and attempt to save over the result to prove the lock (as seen later, qbittorrent does not log the fact that the file was locked).

05-rename_action.png: Right-clicking on the "folder 1" inside of qbittorrent's Content pane and choosing "Rename..." to rename the entire folder and all its contents.

06-rename_prompt.png: The folder rename prompt, choosing "folder 2" as the new name.

07-rename_initial_result.png: The immediate results in the UI of renaming the folder, before touching anything. This is significant because the UI is transiently incorrect and seems to show that all files were successfully moved despite the known locked file.

08-release_lock.png: Release the lock in powershell and do another recursive ls to show the content split across two folders.

09-rename_real_result.png: Click away from the current torrent and back onto it to see the Content pane properly updated, reflecting the files split across both folders.

10-log.png: The execution log with no relevant entries.

As originally described, the torrent's contents are now split across two folders where they were originally stored in one.

---

As for it being irreversible, there's a check at src\gui\propertieswidget.cpp:727 if the folder being renamed to already exists which immediately halts the rename. This is only performing a startsWith match, which isn't a guaranteed conflict when renaming a folder: you would have to compare all the individual path-replaced files similar to how the force_recheck flag is set at line 742. Assuming that more detailed existence check succeeded, it would be another question if the nativeInfo()->rename_file at torrentinfo.cpp:217 correctly merges the folders on all relevant client operating systems, or if you would need to walk through and attempt to move each file/folder in the folder structure individually to handle some clients (thinking especially of XP here).

[chrishirst]

Not quite sure what your point is.

If libtorrent finds a 'file' or piece that is missing, corrupted, locked or otherwise broken it WILL at least attempt to repair the payload if it can, by downloading the 'missing' pieces using the information in the metadata, and by the sounds of it you are 'breaking' the payload and libtorrent is promptly repairing the problem.

[DrKittens]

Personally i dont see this as a concern, likely because i dont move qbittorent files around like that, i move/rename the folder in explorer (errors here if theres a problem like lockfiles/in use) then i change the torrent destination in qbittorent via right click > set location.

If you need to initially change a path directory inside qbtorrent for some reason why not perform it on this screen?
http://i.imgur.com/4896Ofa.png

If i understand your scenario/proposal correctly you're saying that instead of performing the folder split/move it would be better for qbittorent to detect a failure to move due to a locked file (or other) and cancel the update/change & inform the user eg "foo.txt is currently locked, changing this option will result in a folder split, Do you wish to continue"
If that's correct and practical i agree with it been a useful thing to have, although it will very rarely ever be seen by the average user.

Tl;dr libtorrent handling this functionality works as intended, whats missing would be better detection for when this scenario occurs + a user prompt to confirm/deny the change/folder split yes?

[keseph]

--Preface: I have not and continue to not mention "libtorrent" because this is about UI functionality, and was never about chunks or downloads. At no point was any file or chunk orphaned from its download or forced to repair or re-download.
_
DrKittens: If you're using the Watched Folder functionality, then that screen is never presented. You also missed the detail that the folder being renamed is a subfolder inside of the main destination folder, and therefore cannot be changed by changing the main destination otherwise I normally do the exact same as you describe.
Detection after-the-fact that a file failed to rename is demonstrably already happening since the model isn't being desynced from the filesystem and orphaned, but it should log an error that the user's action failed and the UI should not incorrectly show the file as having moved when it didn't (picture 07 above). Following that, my subjective opinion is that a user naively retrying the rename action has a straightforward enough answer (merge into the destination) that it ought to just succeed.
_
In the more general case, when a torrent contains more than just a single .iso, you may want to organize the files in a folder layout different from what the original torrent creator provided but doing so requires a much more complicated UI with a lot more margin for debate.

[kageurufu]

I just hit this same issue

In my case, I'm renaming and organizing multiple files to match my expected folder and file structure. While renaming the parent downloaded folder ("Show.S02" to "Season 2", its downloaded within a parent folder for the show), a single file was locked and I'm now stuck with multiple child folders. I had to remove and re-add the torrent (re-fixing the file names) to fix this

[sledgehammer999]

This issue has been closed and locked for being too old, and thus either most likely resolved in recent versions or no longer applicable.
If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.

A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.

Thank you for your contributions.