Transmission 3.0 torrent File badly renamed :(

[pcp]

Hello there,

A new problem with transimisison 3.0:

when you add a torrent file to transmission it create a copy of this torrent file in: macos/user/username/library/application support/transmission/torrents/

before version 3.0 the created torrent was named exactly like you torrent file, for example : if your torrent file was : file1.zip your torrent file was file1.torrent

so you can easly match the file and the torrent.

Now with version 3, your file1.zip is corresponding to an incredible name like 0b04saghh78derdhf5s.torrent

so you can't match files and their torrent files.

that's really bad i really need to make this 1 or 2 times a year to see i have if files taking space in my hard drive who is not seeded. It's clearly very usefull to clean your hard drive by deleting not seeded files! last time à did that i got back about 1,2TB !

[std01077]

I updated yesterday too and discovered in horror that all my 800 .torrent files had been renamed! I have different reasons to @pcp, but I also need the files to retain their name and not be renamed into something encoded (I'm cataloguing my torrent files and pulling imdb data based on the filenames) but portability and manageability is another reason. Any chance that we can revert to the old filename schema?

[mike.dld]

Two reasons you should not rely on torrent filenames:
1. Files stored in "torrent" and "resume" subdirectories are best managed by Transmission and should not generally be touched by a human. In particular, .torrent and .resume files are stored for Transmission's internal use and could be considered its implementation detail (other BT clients store this information differently); as such, its format may change at any time without notification. Manually manipulating those files may lead to Transmission being unable to load any or all information they contain. Accessing those files directly and relying on their particular structure or naming you accept the risks.
2. The one and only correct source of information about the torrent name is file contents, not its name. The name may contain characters that aren't considered valid by your file system or operating system, meaning that Transmission cannot use the actual name as filename. Granted, in *NIX world this is usually less of a concern as invalid characters usually only include path components separator (forward slash) and zero/null byte, but e.g. improperly configured locale could still potentially lead to issues; this is not the case when you're using Transmission on Windows or sharing files between Windows and *NIX systems. And in any system, there's usually a restriction on the maximum filename or complete path length.

For the reasons above, I'm against reverting to the old naming. In case you need to get the information "the right way" though, I'm sure someone will be able to help.

[std01077]

thanks mike.dld! Your arguments certainly make sense; And of course we have to accept such risks when accessing files in a folder that is not supposed to be user-accessible. Personally I like being able to access stuff directly on the filesystem; not only as entries via a blackbox UI - I like my music and photos, ebooks, notes and .torrents to be actual files in folders and to switch between the two paradigms. I don't like file consolidating solutions like itunes, lightroom or apple photos.
In any case, the decisions of the dev team are much more informed and apparently reverting back to hashed names was a practical choice; I've merely voiced my personal preference for a human-readable format

In any case, you have my gratitude for putting all this work in such a nice program!!
Cheers!

[pcp]

As std01077 i also always manage my files in the finder. IT's totally crappy to do that though an application. And it's important to know where are files on your systems, it save me a lot of times or it just SAVE ME from the loss of many files when installing a new hard drive etc...
When you need to clean you system there is NO BETTER WAY to do that manually by hands! an automatic cleaner software can't know or decide if you need to delete or keep a preference file for an application you don't use anymore etc... (it's just an example)
For this this point about Transmission 3.0, if you don't want to revert to the old names, please do us a new fonctionality to compare the seeded files in 1 or severals directory with the real content of this/these directories. So we will be able to delete the unseeded files and save LOTS of space.
(excuse me for my bad english)