file position within directory changes upon torrent completion

[m1b]

With the introduction of the .part mechanism for incomplete torrents, a user can no longer rely on the icon location of the final torrent after having moved the .part to a desired spot.

• Start a torrent
  
• Wait for the .part to be created
  
• Move the .part to where you want that file to be (eg on the Desktop)
  
• Wait for the torrent to complete
  

-> The process of changing the .part to the final filetype will reset the icon location, moving it from where the user placed the .part

It would be nice if T could maintain any user-made icon location changes from .part to final since this was the behavior in prior releases where no .part was used.

Reproduces in any .part-creating nightly up to and including r9523, 10.5.8.

[livings124]

You could never move the data by hand while downloading/seeding, regardless of this extension. Use File > Move Data File To... instead.

[m1b]

Pls reread the original bug description. I am not talking about moving the data file in the filesystem sense; I am talking about moving the file in the icon-on-desktop sense.

Eg, under 1.76, with the file set to download into ~/Desktop:

• Start single file torrent for foo.bar
  
• Wait for foo.bar to appear on Desktop
  
• Move foo.bar to a specific location on Desktop
  
• Upon file's completion, foo.bar does not move

Under current nightlies, the file's icon position will be reset, and the file WILL move on the Desktop, during the transition from foo.bar.part to foo.bar.

What I'm not certain about is whether this is a Mac client issue or a libT issue.

[livings124]

This is an interesting observation. If anything, it is an issue with how libtransmission renames the file. I'll have to look into this a bit more.

[livings124]

The standard STD rename() function is used. The effort to fix this on our end is definitely not worth it. Please report this upstream, or reopen with more info if there's anything reasonable we can do.