After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 575848 - Aborted copy operations do not close destination files and keep removable disks in use
Aborted copy operations do not close destination files and keep removable dis...
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
3.20.x
Other All
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-18 15:58 UTC by Sam Morris
Modified: 2016-11-13 08:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sam Morris 2009-03-18 15:58:48 UTC
Please describe the problem:
I was downloading a file via SFTP with nautilus when my Internet connection was interrupted. The download progress hung, and I cancelled the operation. But even after closing the file operations window, nautilus still had the destination file open. Since this was on a removable disk, it meant that I could not eject the disk without first killing nautilus!

Steps to reproduce:
1. 
2. 
3. 


Actual results:
Nautilus had the destination file open

Expected results:
It should close the destination file when the copy is cancelled or interrupted

Does this happen every time?


Other information:
Comment 1 Alexander Larsson 2009-03-19 16:10:32 UTC
Closing the transfer window doesn't cancel the operation though. It just minimizes it. Did you press the cancel button in the transfer dialog?
Comment 2 Sam Morris 2009-03-19 22:46:11 UTC
AFAIR, I aborted the transfer with the cancel button, and then (when the transfer window did not close) I closed it myself.
Comment 3 Alexander Larsson 2009-03-20 11:11:59 UTC
So, I think the problem is rather that the cancel operation didn't work.
Comment 4 Sam Morris 2009-03-24 15:14:02 UTC
Sounds reasonable. The cancel button *does* grey out, but the transfer window remains open.
Comment 5 Alexandre Franke 2016-11-13 08:07:57 UTC
Transfer from a remote source cancel just fine now. It takes a bit of time before activity on the target stops, but that's expected since the parts that were written need to be undone.
Comment 6 Alexandre Franke 2016-11-13 08:26:31 UTC
Actually file gets written on the target, that's bug 403652.