Adding Torrent with Subfolder screws Folder view in TRGUI

[Tharn]

When I add a torrent to D:\ISOs, where on D:\ there are several torrent subfolders and transmission-daemon uses D:\ as its torrent directory, the following happens:

It loads and starts fine in Tremotesf. It looks fine in the Tremotesf folder list. However.

In TRGUI, where usually subfolders are shown without drive labels, such as

ISOs
PDFs
ETC

After having added 1 torrent explicitly to D:\ISOs with Tremotesf, it now shows the following list in TRGUI

D:/ISOs
D:\ISOs
PDFs
ETC

When I move the torrent in TRGUI to fix it, it gives me its current location as D:/ISOs, which is wrong for NTFS.
After doing this, both superfluous listings disappear.

[equeim]

According to Transmission developer, forward slashes should be used by clients when communicating with Transmission, even on Windows (presumably Transmission will convert paths to native format when performing actual IO operations). Tremotesf does as recommended and uses forward slashes on Windows when performing RPC requests to Transmission. In UI they are displayed with backward slashes.

Unfortunately Windows paths are handled poorly by Transmission and it can report paths both with forward and backward slashes (in various cases including when torrent was added by Transmission itself, without the use of remote client). Tremotesf handles this by normalizing paths internally, so that e.g. D:/ISOs and D:\ISOs are treated the same and displayed as one in UI (with backward slashes). Given Transmission (not)handling path separators properly I believe that's what clients should do if they want to correctly handle Transmission running on Windows.

[Tharn]

Fair enough, but that makes Tremotesf an outlier because other remote GUIs don't normalize paths, and a torrent added by Tremotesf uses a forward slash on Windows, which some other GUIs have issues with.

Backslash use for Windows file systems internally in Transmission is no problem because otherwise these other UIs wouldn't work. I don't see the harm in changing this. What I have read, Windows should be able to handle both types, but it is still a non-native way to display a path in Windows traditionally. But it's up to you ofc. Might make an Issue at the other GUI to group the different types better too.