Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3198 closed Bug (duplicate)

Transmission mishandling offline network volume and storing files in an illegal hidden local path

Reported by: photonclock Owned by:
Priority: High Milestone: None Set
Component: Transmission Version: 1.93
Severity: Blocker Keywords: shared volume network file sharing /Volumes
Cc:

Description

System description: Typical home network - standard DHCP with an Apple Airport Extreme Torrents are stored on a shared volume attached to an iMac server sharing the volume via standard Apple file sharing (MacOS 10.5.8) Torrent contents are downloaded to the shared volume.

Example:

1) Mount the SharedVolume?, 2) Moving a previously downloaded file.torrent to /SharedVolume/Torrents?/file.torrent 3) Add file.torrent to Transmission 4) Specify /SharedVolume/Torrents/? as the download path for the torrent contents. 5) Begin downloading the Torrent contents 6) The torrent contents are stored on /SharedVolume/Torrents/TorrentContents? (the torrent being downloaded is a folder full of files)

Problem - steps to reproduce:

1) Mount the SharedVolume? (it's a standard shared volume via Apple file sharing, appears in the "Shared" volumes list in the sidebar of MacOS 10.5.8) 2) Launch Transmission 3) Partially download the torrent 4) Pause the download. 5) Quit Transmission. 6) Unmount the SharedVolume?. Make SharedVolume? unavailable on the network if necessary to reproduce this (reason: I do not know if it's easily reproducible for Transmission to fail to automatically re-mount the SharedVolume?, but that is what happens in my case) 7) Relaunch Transmission 8) Continue the download (even though shared volume remains offline)

Result:

Transmission creates a local COPY of the path to the SharedVolume? on the LOCAL computer, improperly hidden within the MacOS folder "/Volumes/". The folders Transmission creates are real folders, not a reference to the actual /SharedVolume?. Transmission begins re-downloading and storing all the files contained within the torrent at this hidden path.

This illegal local path is: /Volumes/SharedVolume/Torrents/TorrentContents?

Normally, aliases or symlinks to local volumes are contained in the /Volumes folder on MacOS X. In this case, the "SharedVolume?" described in the above path is NOT an alias or reference to the real "SharedVolume?". It's a real folder, created by Transmission, on the local computer, filled with folders and files hidden from the user.

The actual network volume /SharedVolume? does not get re-mounted automatically in the above reproduce steps. This path called "/Volumes/SharedVolume/Torrents/TorrentContents?" containing all of the files within the torrent is created when the real /SharedVolume? is offline.

Since the "/Volumes" folder is a special Mac OS folder which is not visible to the user via the Finder, all the files Transmission downloads are now being stored in this hidden path, unknown to the user.

I discovered this when I examined the contents of my hard drive with Path Finder (viewing invisible files/folders). There, at the root of my local system drive, was the path: /MacBook? System/Volumes/SharedVolume/Torrents/TorrentContents/?

This folder was eating up tons of hard drive space, because every time I had restarted a Torrent with the real SharedVolume? offline, Transmission started downloading the files in this path.

I think this is a very serious bug. I hope I've provided enough info to reproduce it and get it fixed.

Attached, a screenshot (using Path Finder) of the hidden path Transmission creates within the /Volumes folder on the local computer when the network volume is offline.

Attachments (1)

Picture 1.png (56.8 KB) - added by photonclock 8 years ago.
screenshot

Download all attachments as: .zip

Change History (5)

Changed 8 years ago by photonclock

screenshot

comment:1 Changed 8 years ago by charles

  • Resolution set to duplicate
  • Status changed from new to closed

This appears to be a duplicate of #2336

comment:2 Changed 8 years ago by photonclock

I disagree that this is a duplicate. A bug report should be judged based on the specific reported behavior. It shouldn't be automatically closed just because the code under consideration may be tangentially related to different behavior described in another bug report.

#2336 describes a different symptom when using removable media (USB drives). #3198 describes behavior using network volumes. It's two different (possibly related) bugs.

That said, I'll just link them with these comments and hope for a fix soon.

Thanks!

comment:3 Changed 8 years ago by howl

And I'm pretty sure that what you have described should be summarized like a comment in the other bug report. The same bug came have more than one missbehaviours, bug that doesn't mean that a new ticket should be made for each one.

comment:4 Changed 7 years ago by charles

#2336 has been superceded by #2955

Note: See TracTickets for help on using tickets.