Transmission keeps seeding after downloaded file has been deleted
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?
filesystems transmission
add a comment |
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?
filesystems transmission
add a comment |
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?
filesystems transmission
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
filesystems transmission
edited May 4 '16 at 20:32
asked May 4 '16 at 20:26
Tango
11
11
add a comment |
add a comment |
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
add a comment |
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.
add a comment |
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
add a comment |
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
add a comment |
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
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
edited 2 days ago
Benoit C.
286
286
answered May 4 '16 at 22:26
Henrik
3,5831419
3,5831419
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Apr 13 '17 at 12:36
Community♦
1
1
answered May 4 '16 at 21:30
BenjaminH
22628
22628
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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