-
Notifications
You must be signed in to change notification settings - Fork 413
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
auto move: strange default path involving df output causing paused state #2699
Comments
possibly related: when attempting to move torrents from the broken path to correct dir, I sometimes get "DataDir plugin: operation fail" |
@fiver22 Could you upgrade to ruTorrent |
Happy to ask that they upgrade. I will ask and report back what I can. |
Was able to upgrade to 4.3.6. the error now presents as save path = I hope this can be of some use. |
Could you provide a screenshot of the autotools tab in your settings menu? |
Please complete the following tasks.
Tell us about your environment
Web Browser: latest firefox stable , latest chrome stable, n/a
ruTorrent Version: v4.3.5
PHP Version: PHP 8.1.2-1ubuntu2.18
Operating System: Ubuntu 22.04.4 LTS
Tell us how you installed ruTorrent
seedbox provider installed -hopefully they will add detail
Describe the bug
Occasionally, approximately 1 out of every 30 torrents, torrents are saved to incorrect paths that include unintended concatenations of system outputs and the intended paths. This issue seems to trigger timeouts and loading errors in ruTorrent.
Example of Incorrect Save Path:
Path format with spacing detailed:
/dev/sdae1␣498814504␣␣2929687500␣␣␣␣␣␣␣0␣␣␣␣␣␣␣␣16513␣␣␣␣␣␣␣0␣␣␣␣␣␣␣0␣␣␣␣␣␣␣␣/home14/{user_name}/downloads
Steps to reproduce
Add torrents as usual.
Observe the save path for each torrent.
Note that approximately 1/30 torrents exhibit the issue described.
Expected behavior
All torrents should be saved to the designated save path, in this case: /home14/{username}/downloads
Additional context
This issue occurs on a shared slot provider where I do not have root access. I have already opened a ticket with the provider, and they suggested posting this bug report.
Possibly related issue: #1585
The text was updated successfully, but these errors were encountered: