New Torrent via RPC Error:No data found when subfolder does not exist

[lazybones]

I use the transmission daemon via flexget which uses RPC calls and have previously been able to specify the download path such where the target subfolder did not exist and transmission would just create it. This was handy as it only required adding the new target in one place and the folder would just be created.

The error states to use set location to re add the torrent, this can't be done from the UI and a start and stop of the daemon does not fix the paused state even once the folder has been created.

IE /mnt/disk1/media exists /mnt/disk1/media/newtarget does not exist

I assume something has changed around the improvements for removable disks in 2.31?

[Doetje]

I can confirm this rather annoying bug. Adding torrents via an RPC client no longer works since updating to 2.31 if you specify a non-existing folder to download to. Transmission-gui (Windows), flexget, ... all suffer from this issue.

Is there a specific reason why folders are no-longer created if necessary or is this a bug?

[zyxmon]

I do confirm this bug in 2.32. I hope it'll be fixed.

[jordan]

This behavior was introduced in r12076. The reason is to prevent directories from being created in error. One common complaint was Transmission creating an external drive's directory path when the drive was unplugged.

[lazybones]

• Drives almost never get detached on a server system running a daemon.
• The FIX leaves no way to create new folders via RPC clients
• The FIX creates no way to resolve / recover torrents that have a new path set when created

How many people use transmission with removable drives? This appears to be a subset of users likely limited mostly to laptops and ONLY the desktop editions of transmission.

This very much breaks the remote usefulness of teh daemon, which has been one of transmissions strongest features for a long long time and makes it popular on headless NAS solutions.

[jberzins]

How about to check if the root of the path is part of /proc/self/mounts instead of being this drastic. Or an easy fix - a configuration parameter to bypass this feature for those with perma-mounted partitions.

Unfortunately I do not have enough C/C++ skills to implement it myself.

This is not lethal problem but a bit annoying to make the directories by hand for new shows/seasons.

Thanks, jb

[lazybones]

The root path might be a problem since Windows / Mac / Unix systems can have paths with symbolic links and different mount points.

A compromise might be to allow one level deep new folder creation, where the path check is done twice, once for the full path, and if that does not exist check its parent path.. it would be fairly safe to assume that if /mnt/drive/Coolstuff/new does not exist but /mnt/drive/Coolstuff does exit that it is safe to create the needed folder.

I use Transmission on my NAS running as a daemon, via Transmission Remote GUI as if it was a normal desktop client, and it worked great until this change as now I have to do all the file management after the download on the server, where before I could quickly organize new downloads into folders.

[jordan]

That compromise would fail for situations like /mnt/drive/ubuntu-11.04-i386.iso ...

Maybe I'm imagining the symmetry here, but in light of the discussion at https://trac.transmissionbt.com/ticket/1496#comment:16, maybe that proposal of adding "a predefined set of download paths" to Transmission could be used here too: subdirectories could be freely created underneath the download path, as long as the download path existed.

I'm not sure how well this would work in practice. It could add another level of complexity (the set of download directories) that could conceivably be a nuisance for someone wanting to download a one-off torrent to /tmp. Also, I'm not sure how we would configure this in the GUI clients.

[jordan]

Ticket #4352 has been closed as a duplicate of this bug.

[jordan]

Alternately, we could just undo r12076. The most common use case (unplugged external drives) will still be detected by the "No data found!" tests anyway...

[lazybones]

Since I never plan on saving torrents to a removable dive that works fine for me...

Not sure about other users.

I still think that checking that the parent directory exists would be a good compromise..

Isn't the original complaint that deep paths where being created in the wrong place if the drive was removed?

In this compromise users are limited to creating one folder if anything, and unless the users was storing to the ROOT of the removable drive (a bad idea on some files systems anyway) it would still work for detecting the path was missing in most cases... Assuming again that that the original complain was due to the target having some form of directory structure that was being recreated in the wrong place.

[seizmo]

I would also very much appreciate this bug being fixed!

If there will be an option it should be to switch the new behaviour (not creating directories) ON. It is my belief that there are much less users storing their torrents on removable devices than there are users which use flexget or transmission-gui to automate or remote-control transmission. For both these user groups, transmission is much less useful with this new behaviour.

[kxalex]

Voting for fixing it as that bug forced me to roll back to 2.22. I store torrents to external drive all the time. Please fix it.

[jordan]

r12076 has been reverted by r12582, which should fix the problem.

Could someone run a nightly build to doublecheck the fix?

[kxalex]

I tried on 2.33+ #12595 and it worked for me. So, looks like it's fixed. Thanks.

UPDATE: looks like the issue is still there, but it shows itself after restart.

[jordan]

I'm still not seeing this behavior. If you're experiencing it post-r12582, could you please list the specific steps that you're using to trigger it, so that I can reproduce the behavior in my tests?

[lazybones]

I haven't been able to try the nightly since I no longer have a build environment to cross compile for my NAS... Simply haven't had the personal time to check this..

[jordan]

kxalex, do you have any more information on comment:16 that the issue is still there, but shows itself after restart? Especially helpful would be a walkthrough of the steps to reproduce the bug in an up-to-date svn version of Transmission.

[kxalex]

@jordan, i have removed transmission pref settings and it works fine now. so, probably settings got messed up. yesterday I have updated to latest build and no issues observed yet.

Thanks.

[jordan]

Thanks for the response. I'm going to close this ticket as fixed, but if you see any regression please reopen it with more information. Thanks!

[lazybones]

Forgot to come back and confirm that YES it is fixed.

Thank-you