1. Start Tribler.
2. In browser-based GUI, use "Add torrent -> Create torrent from file(s)"
3. Fill in Name, Description fields, add files (in this case, they are already in /home/tribler/TriblerDownloads)
4. Leave "Torrent file destination" default (in my case, /home/tribler/TriblerDownloads).
5. Check "seed this torrent after creation" and press "create torrent" button.

Expected

It adds new download in "Seeding" state with the name I typed in the "Name" field previously. I can access (and maybe adjust) the description.

Created torrent file has "Name" attribute that I used when creation.

Actual

"Name" seems to be used only to name the torrent file placed in the directory.

Tribler GUI and torrent file's "Name" attribute shows TriblerDownloads, i.e. the directory where the files are from and where the torrent file was placed.

No traces of information I typed in the text fields are visible from Downloads section of Triber web interface.

Thanks for the report! I can reproduce this.

I just found the code for this:

https://github.com/Tribler/tribler/blob/98d389e6d601d634e79b3a4f4052f5976dc83320/src/tribler/core/libtorrent/torrents.py#L135-L141

This is simply taking the common base name as the torrent name, completely ignoring the actual name that was passed in the params. I will note that the comment itself is correct, though.

---

After some code archeology, this seems to have worked 10 years ago:

https://github.com/Tribler/tribler/blob/06238fc2e0738831603279bd6c88a9259eae0316/Tribler/Core/APIImplementation/maketorrent.py#L190-L195

The main problem, also for #4674, is that our torrent library seeds from directories that have the same name as a torrent. Right now, we assume that users have a single directory that is named the same as the torrent and has the torrent files in the directory. Or, a single file for which the name is the same name as the torrent file. Essentially, the "Name" field is useless.

So, as I see it, we have two options:

1. Keep doing what we're doing: remove the "Name" field and tell our users that all the files should already be in the same directory.
2. Allow users to compose torrents from files in different directories and copy over the files into the torrent download directory with the chosen torrent name. This copying can be very slow and (likely) doubles disk usage. We might be able to save space by using "soft links" to the original file locations (even if this works, this will still make as many soft links as there are files in the torrent). This is (way) more annoying for us to implement, but this is probably what users expect. As an aside, allowing files to come from "other" locations also requires a GUI redesign to have both a "new path in torrent" and a "current source path on disk".