error Couldn't open "path-to-file.part": Permission denied

Asked by Phil Colbourn on 2011-01-25

Binary package hint: transmission

When this error happens, Transmission Pauses all activity.
It is followed by these two messages:

error Couldn't open "path-to-file.part": Permission denied
error <torrent> tr_fdFileCheckout failed for "path-to-file.part": Permission denied
<torrent> Pausing

I tried un-ticking this file so that it would not be downloaded, but the error eventually happened again - about 7 hours later - which is better than normal where if fails after a few minutes.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: transmission-gtk 2.05-0ubuntu0.1
ProcVersionSignature: Ubuntu 2.6.35-25.43-generic
Uname: Linux 2.6.35-25-generic x86_64
NonfreeKernelModules: nvidia wl
Architecture: amd64
Date: Wed Jan 26 08:54:32 2011
ExecutablePath: /usr/bin/transmission
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
SourcePackage: transmission

Question information

English Edit question
Ubuntu transmission Edit question
No assignee Edit question
Last query:
Last reply:
Phil Colbourn (philcolbourn) said : #1
Phil Colbourn (philcolbourn) said : #2

I have since deleted the offending file, forced a verify and all is well so far. Nautilus showed a padlock indicating that the permissions were wrong - how would that happen?

Unfortunately, in my enthusiasm in locating the probably cause of the fault, I deleted it without checking the permissions.

Phil Colbourn (philcolbourn) said : #3

All seems ok.

I suspect the file's permissions were the real cause.

Only one file had incorrect permissions. I suspect/guess that I may have started Transmission as root for a few seconds, and this must have been the file that was created during that time.

But, could the program continue to work on other files and provide a warning instead of stopping?

Phil Colbourn (philcolbourn) said : #4

Problem resolved and not a bug. But I asked whether the error handling behavior could be changed.

"But, could the program continue to work on other files and provide a warning instead of stopping?"

That would probably not be a very good design choice. If some files cannot be written to, there is no reason to believe that the user wants the torrent to continue downloading at all--perhaps the user neglected to set restrictive permissions on the other files, for example. Furthermore, often the user might not want to waste resources like bandwidth and disk space downloading parts of torrents which cannot actually complete due to a problem on their machine. If the user wants it to continue downloading, they can fix the problem. (This is different from a torrent that has fewer than one distributed copy; in that case, network conditions could easily change to make it possible for the torrent to finish, and since this is largely outside the control of the user, there is no reason to assume that the user doesn't want the torrent to continue.)

Can you help with this problem?

Provide an answer of your own, or ask Phil Colbourn for more information if necessary.

To post a message you must log in.