Transmission keeps seeding after downloaded file has been deleted

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












I'm using Transmission 2.82 on Xubuntu 14.04, and I noticed that after I deleted the downloaded file permanently from files manager, the job in Transmission was still active and kept seeding, and there was no change in free disk space, so I tried ls -l /proc/[pid]/fd and I got this:



lr-x------ 1 name name 64 May 4 20:39 81 -> /home/downloads/ubuntu-16.04-server-i386.iso (deleted)



then I redownloaded the file and deleted it with rm without deleting the job and the disk space was freed and ls -l /proc/[pid]/fd gived no entry related to the file and the job was seeding at 0kb/s.



but to see if it was rm that made the difference, I then tried three times delete the downloaded file with rm while the job was seeding, and each times I received the same result, the jobs were active and seeding, no change in free disk space, and ls -l /proc/[pid]/fd yielded something like:



lr-x------ 1 name name 64 May 4 20:39 26 -> /home/downloads/ubuntu-16.04-server-i386.iso (deleted)



and ls ubuntu-16.04-server-i386.iso gived:



ls: cannot access ubuntu-16.04-server-i386.iso: No such file or directory



I also tried du -s and df /home in the download folder with another job respectively when:



Job running, file undeleted:
$ du -sh
11G
$ df -h /home
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 58G 54G 1.2G 98% /



Job running, file deleted(with rm) (and Transmission keeps seeding after deletion):
$ du -sh
9.9G
$ df -h /home
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 58G 54G 1.2G 98% /



Job deleted, file deleted(in previous step):
$ du -sh
9.9G
$ df -h /home
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 58G 54G 1.5G 98% /



So, what happened to the downloaded file? After I rm it, how Transmission is still seeding the job? Is it possible to restore the file? Since du and df give different outputs, is the file relocated to some other place?










share|improve this question



























    up vote
    0
    down vote

    favorite












    I'm using Transmission 2.82 on Xubuntu 14.04, and I noticed that after I deleted the downloaded file permanently from files manager, the job in Transmission was still active and kept seeding, and there was no change in free disk space, so I tried ls -l /proc/[pid]/fd and I got this:



    lr-x------ 1 name name 64 May 4 20:39 81 -> /home/downloads/ubuntu-16.04-server-i386.iso (deleted)



    then I redownloaded the file and deleted it with rm without deleting the job and the disk space was freed and ls -l /proc/[pid]/fd gived no entry related to the file and the job was seeding at 0kb/s.



    but to see if it was rm that made the difference, I then tried three times delete the downloaded file with rm while the job was seeding, and each times I received the same result, the jobs were active and seeding, no change in free disk space, and ls -l /proc/[pid]/fd yielded something like:



    lr-x------ 1 name name 64 May 4 20:39 26 -> /home/downloads/ubuntu-16.04-server-i386.iso (deleted)



    and ls ubuntu-16.04-server-i386.iso gived:



    ls: cannot access ubuntu-16.04-server-i386.iso: No such file or directory



    I also tried du -s and df /home in the download folder with another job respectively when:



    Job running, file undeleted:
    $ du -sh
    11G
    $ df -h /home
    Filesystem Size Used Avail Use% Mounted on
    /dev/sda1 58G 54G 1.2G 98% /



    Job running, file deleted(with rm) (and Transmission keeps seeding after deletion):
    $ du -sh
    9.9G
    $ df -h /home
    Filesystem Size Used Avail Use% Mounted on
    /dev/sda1 58G 54G 1.2G 98% /



    Job deleted, file deleted(in previous step):
    $ du -sh
    9.9G
    $ df -h /home
    Filesystem Size Used Avail Use% Mounted on
    /dev/sda1 58G 54G 1.5G 98% /



    So, what happened to the downloaded file? After I rm it, how Transmission is still seeding the job? Is it possible to restore the file? Since du and df give different outputs, is the file relocated to some other place?










    share|improve this question

























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I'm using Transmission 2.82 on Xubuntu 14.04, and I noticed that after I deleted the downloaded file permanently from files manager, the job in Transmission was still active and kept seeding, and there was no change in free disk space, so I tried ls -l /proc/[pid]/fd and I got this:



      lr-x------ 1 name name 64 May 4 20:39 81 -> /home/downloads/ubuntu-16.04-server-i386.iso (deleted)



      then I redownloaded the file and deleted it with rm without deleting the job and the disk space was freed and ls -l /proc/[pid]/fd gived no entry related to the file and the job was seeding at 0kb/s.



      but to see if it was rm that made the difference, I then tried three times delete the downloaded file with rm while the job was seeding, and each times I received the same result, the jobs were active and seeding, no change in free disk space, and ls -l /proc/[pid]/fd yielded something like:



      lr-x------ 1 name name 64 May 4 20:39 26 -> /home/downloads/ubuntu-16.04-server-i386.iso (deleted)



      and ls ubuntu-16.04-server-i386.iso gived:



      ls: cannot access ubuntu-16.04-server-i386.iso: No such file or directory



      I also tried du -s and df /home in the download folder with another job respectively when:



      Job running, file undeleted:
      $ du -sh
      11G
      $ df -h /home
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda1 58G 54G 1.2G 98% /



      Job running, file deleted(with rm) (and Transmission keeps seeding after deletion):
      $ du -sh
      9.9G
      $ df -h /home
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda1 58G 54G 1.2G 98% /



      Job deleted, file deleted(in previous step):
      $ du -sh
      9.9G
      $ df -h /home
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda1 58G 54G 1.5G 98% /



      So, what happened to the downloaded file? After I rm it, how Transmission is still seeding the job? Is it possible to restore the file? Since du and df give different outputs, is the file relocated to some other place?










      share|improve this question















      I'm using Transmission 2.82 on Xubuntu 14.04, and I noticed that after I deleted the downloaded file permanently from files manager, the job in Transmission was still active and kept seeding, and there was no change in free disk space, so I tried ls -l /proc/[pid]/fd and I got this:



      lr-x------ 1 name name 64 May 4 20:39 81 -> /home/downloads/ubuntu-16.04-server-i386.iso (deleted)



      then I redownloaded the file and deleted it with rm without deleting the job and the disk space was freed and ls -l /proc/[pid]/fd gived no entry related to the file and the job was seeding at 0kb/s.



      but to see if it was rm that made the difference, I then tried three times delete the downloaded file with rm while the job was seeding, and each times I received the same result, the jobs were active and seeding, no change in free disk space, and ls -l /proc/[pid]/fd yielded something like:



      lr-x------ 1 name name 64 May 4 20:39 26 -> /home/downloads/ubuntu-16.04-server-i386.iso (deleted)



      and ls ubuntu-16.04-server-i386.iso gived:



      ls: cannot access ubuntu-16.04-server-i386.iso: No such file or directory



      I also tried du -s and df /home in the download folder with another job respectively when:



      Job running, file undeleted:
      $ du -sh
      11G
      $ df -h /home
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda1 58G 54G 1.2G 98% /



      Job running, file deleted(with rm) (and Transmission keeps seeding after deletion):
      $ du -sh
      9.9G
      $ df -h /home
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda1 58G 54G 1.2G 98% /



      Job deleted, file deleted(in previous step):
      $ du -sh
      9.9G
      $ df -h /home
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda1 58G 54G 1.5G 98% /



      So, what happened to the downloaded file? After I rm it, how Transmission is still seeding the job? Is it possible to restore the file? Since du and df give different outputs, is the file relocated to some other place?







      filesystems transmission






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited May 4 '16 at 20:32

























      asked May 4 '16 at 20:26









      Tango

      11




      11




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          2
          down vote













          If a program has a file open when you delete it, the kernel only marks it as deleted, but doesn't free the disc space, to avoid breaking the program (it's can't know if the file is important to the function of the program). When the program closes the file the disc space is freed. When that happens you will see the "(deleted)" when you look at /proc/<pid>/fd for the process that has the file open.



          So this is the kernel being helpful in not removing a file that transmission uses.



          If you don't want to share a file using transmission you should remove it from transmission, as far as I remember transmission even has an option for deleting the files as part of stopping to share it.



          You can actually restore the file by copying it from /proc/<pid>/fd/ since it is a link to the file (just one that only exists as long as the process has it open).



          root@mypc:~# pgrep transmission
          1470
          root@mypc:~# cd /proc/1470/fd
          root@mypc:/proc/1470/fd# ls -l | grep deleted
          lr-x------ 1 user user 64 Dec 8 02:55 56 -> /mnt/download/my.file (deleted)
          root@mypc:/proc/1470/fd# cp 56 /mnt/download/myrestored.file





          share|improve this answer





























            up vote
            0
            down vote













            I suspect transmission saves the file to a location unknown to you when downloading. After it is finished it creates a hardlink to that same file in your download folder, but still keeps the hardlink in it's own directory(probably ~/.transmission or something like that).



            You can find all hardlinks to the finished download as explained in How to find all hard links to a given file? or use this:
            Go to ~/Downloads execute ls -i and remember the inode-number for your file. Then you can find the other file by executing find . -inum NUM in your home folder.






            share|improve this answer






















              Your Answer








              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "106"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              convertImagesToLinks: false,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              imageUploader:
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              ,
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );













              draft saved

              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f281133%2ftransmission-keeps-seeding-after-downloaded-file-has-been-deleted%23new-answer', 'question_page');

              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              2
              down vote













              If a program has a file open when you delete it, the kernel only marks it as deleted, but doesn't free the disc space, to avoid breaking the program (it's can't know if the file is important to the function of the program). When the program closes the file the disc space is freed. When that happens you will see the "(deleted)" when you look at /proc/<pid>/fd for the process that has the file open.



              So this is the kernel being helpful in not removing a file that transmission uses.



              If you don't want to share a file using transmission you should remove it from transmission, as far as I remember transmission even has an option for deleting the files as part of stopping to share it.



              You can actually restore the file by copying it from /proc/<pid>/fd/ since it is a link to the file (just one that only exists as long as the process has it open).



              root@mypc:~# pgrep transmission
              1470
              root@mypc:~# cd /proc/1470/fd
              root@mypc:/proc/1470/fd# ls -l | grep deleted
              lr-x------ 1 user user 64 Dec 8 02:55 56 -> /mnt/download/my.file (deleted)
              root@mypc:/proc/1470/fd# cp 56 /mnt/download/myrestored.file





              share|improve this answer


























                up vote
                2
                down vote













                If a program has a file open when you delete it, the kernel only marks it as deleted, but doesn't free the disc space, to avoid breaking the program (it's can't know if the file is important to the function of the program). When the program closes the file the disc space is freed. When that happens you will see the "(deleted)" when you look at /proc/<pid>/fd for the process that has the file open.



                So this is the kernel being helpful in not removing a file that transmission uses.



                If you don't want to share a file using transmission you should remove it from transmission, as far as I remember transmission even has an option for deleting the files as part of stopping to share it.



                You can actually restore the file by copying it from /proc/<pid>/fd/ since it is a link to the file (just one that only exists as long as the process has it open).



                root@mypc:~# pgrep transmission
                1470
                root@mypc:~# cd /proc/1470/fd
                root@mypc:/proc/1470/fd# ls -l | grep deleted
                lr-x------ 1 user user 64 Dec 8 02:55 56 -> /mnt/download/my.file (deleted)
                root@mypc:/proc/1470/fd# cp 56 /mnt/download/myrestored.file





                share|improve this answer
























                  up vote
                  2
                  down vote










                  up vote
                  2
                  down vote









                  If a program has a file open when you delete it, the kernel only marks it as deleted, but doesn't free the disc space, to avoid breaking the program (it's can't know if the file is important to the function of the program). When the program closes the file the disc space is freed. When that happens you will see the "(deleted)" when you look at /proc/<pid>/fd for the process that has the file open.



                  So this is the kernel being helpful in not removing a file that transmission uses.



                  If you don't want to share a file using transmission you should remove it from transmission, as far as I remember transmission even has an option for deleting the files as part of stopping to share it.



                  You can actually restore the file by copying it from /proc/<pid>/fd/ since it is a link to the file (just one that only exists as long as the process has it open).



                  root@mypc:~# pgrep transmission
                  1470
                  root@mypc:~# cd /proc/1470/fd
                  root@mypc:/proc/1470/fd# ls -l | grep deleted
                  lr-x------ 1 user user 64 Dec 8 02:55 56 -> /mnt/download/my.file (deleted)
                  root@mypc:/proc/1470/fd# cp 56 /mnt/download/myrestored.file





                  share|improve this answer














                  If a program has a file open when you delete it, the kernel only marks it as deleted, but doesn't free the disc space, to avoid breaking the program (it's can't know if the file is important to the function of the program). When the program closes the file the disc space is freed. When that happens you will see the "(deleted)" when you look at /proc/<pid>/fd for the process that has the file open.



                  So this is the kernel being helpful in not removing a file that transmission uses.



                  If you don't want to share a file using transmission you should remove it from transmission, as far as I remember transmission even has an option for deleting the files as part of stopping to share it.



                  You can actually restore the file by copying it from /proc/<pid>/fd/ since it is a link to the file (just one that only exists as long as the process has it open).



                  root@mypc:~# pgrep transmission
                  1470
                  root@mypc:~# cd /proc/1470/fd
                  root@mypc:/proc/1470/fd# ls -l | grep deleted
                  lr-x------ 1 user user 64 Dec 8 02:55 56 -> /mnt/download/my.file (deleted)
                  root@mypc:/proc/1470/fd# cp 56 /mnt/download/myrestored.file






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Dec 8 at 6:25









                  Benoit C.

                  286




                  286










                  answered May 4 '16 at 22:26









                  Henrik

                  3,5831419




                  3,5831419






















                      up vote
                      0
                      down vote













                      I suspect transmission saves the file to a location unknown to you when downloading. After it is finished it creates a hardlink to that same file in your download folder, but still keeps the hardlink in it's own directory(probably ~/.transmission or something like that).



                      You can find all hardlinks to the finished download as explained in How to find all hard links to a given file? or use this:
                      Go to ~/Downloads execute ls -i and remember the inode-number for your file. Then you can find the other file by executing find . -inum NUM in your home folder.






                      share|improve this answer


























                        up vote
                        0
                        down vote













                        I suspect transmission saves the file to a location unknown to you when downloading. After it is finished it creates a hardlink to that same file in your download folder, but still keeps the hardlink in it's own directory(probably ~/.transmission or something like that).



                        You can find all hardlinks to the finished download as explained in How to find all hard links to a given file? or use this:
                        Go to ~/Downloads execute ls -i and remember the inode-number for your file. Then you can find the other file by executing find . -inum NUM in your home folder.






                        share|improve this answer
























                          up vote
                          0
                          down vote










                          up vote
                          0
                          down vote









                          I suspect transmission saves the file to a location unknown to you when downloading. After it is finished it creates a hardlink to that same file in your download folder, but still keeps the hardlink in it's own directory(probably ~/.transmission or something like that).



                          You can find all hardlinks to the finished download as explained in How to find all hard links to a given file? or use this:
                          Go to ~/Downloads execute ls -i and remember the inode-number for your file. Then you can find the other file by executing find . -inum NUM in your home folder.






                          share|improve this answer














                          I suspect transmission saves the file to a location unknown to you when downloading. After it is finished it creates a hardlink to that same file in your download folder, but still keeps the hardlink in it's own directory(probably ~/.transmission or something like that).



                          You can find all hardlinks to the finished download as explained in How to find all hard links to a given file? or use this:
                          Go to ~/Downloads execute ls -i and remember the inode-number for your file. Then you can find the other file by executing find . -inum NUM in your home folder.







                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited Apr 13 '17 at 12:36









                          Community

                          1




                          1










                          answered May 4 '16 at 21:30









                          BenjaminH

                          22628




                          22628



























                              draft saved

                              draft discarded
















































                              Thanks for contributing an answer to Unix & Linux Stack Exchange!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid


                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.

                              To learn more, see our tips on writing great answers.





                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                              Please pay close attention to the following guidance:


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid


                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.

                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f281133%2ftransmission-keeps-seeding-after-downloaded-file-has-been-deleted%23new-answer', 'question_page');

                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown






                              Popular posts from this blog

                              How to check contact read email or not when send email to Individual?

                              Displaying single band from multi-band raster using QGIS

                              How many registers does an x86_64 CPU actually have?