I have seen this behavior several times, and I do not really like it:
I often need to move large amounts of data from one location to another, e.g. when storing data from a server to an external drive. If I change my mind after initiating the move operation, it can take really long before the operation is cancelled (minutes to hours!!)
It is probably easiest if I describe an actual situation:
On the left hand side I have a number of folders with large amounts of data. One of the folders at hand contains 71 GB of data.
On the right hand side, I have an empty drive.
I select the folder and chose move to right.
Status bar shows a progress bar and "Moving 1 of 1"
After a short while I change my mind, because I need to use the external drive for something else, elsewhere and click on the red circle with the white X next to the progress bar.
At this point apparantly nothing has been copied yet (but that is not true).
The status message changes to "Moving 1 of 1 Waiting 1 Second Remaining".
This stays like this for, as I said above, a very very long time, while nothing seems to happen.
I can see the LED on the external drive blinking like h... and if I try to eject the disc I can't because it is busy.
Doing a fast refresh reveals that BC has indeed started copying files and does not seem to have in mind stopping to do so.
This is of course not so convenient and I see several issues here:
1) cancelling is not immediate - and if I pull out the disc without ejecting, I fear that it will be left in an undefined state, with regard to the files that appear to be copied.
2) There is no user info that tells the user what is going on and why the cancelling is not done.
I have been waiting (while writing this) for 30 min now, and (using fast refresh) I can see that 32 of 71 GB has been copied. I do not know whether the copy will proceed to the end or it will eventually stop.
I believe I have done this before and also used cancel. When the program finally cancelled the process (after copying a large amount of data), the copied data was deleted (which I guess is the correct handling of a cancel request - i.e. to leave thins as they were before the process (move in this case) was started. But then, why copy in the first place??
I can see in the process monitor that the unix command cp is running, and I suspect that BC is just using a system call to cp to first copy the folder and after that deleting the source folder (when moving). This would explain why BC can not halt the process. But I still think you should consider if this is the best way...
one more (general) thing: Why "Moving 1 of 1" when the folder contains numerous folders each with hundreds of files? I understand that only one folder is moved, but from the user standpoint it looks as if nothing happens until the entire folder and all sub items has been processed. I would suggest the text should rather be "Moving 1 of 1 folder (234 of 243662 files)" for instance.
Claus
PS: now at 44.4 GB of 71 GB after 45 min.
I often need to move large amounts of data from one location to another, e.g. when storing data from a server to an external drive. If I change my mind after initiating the move operation, it can take really long before the operation is cancelled (minutes to hours!!)
It is probably easiest if I describe an actual situation:
On the left hand side I have a number of folders with large amounts of data. One of the folders at hand contains 71 GB of data.
On the right hand side, I have an empty drive.
I select the folder and chose move to right.
Status bar shows a progress bar and "Moving 1 of 1"
After a short while I change my mind, because I need to use the external drive for something else, elsewhere and click on the red circle with the white X next to the progress bar.
At this point apparantly nothing has been copied yet (but that is not true).
The status message changes to "Moving 1 of 1 Waiting 1 Second Remaining".
This stays like this for, as I said above, a very very long time, while nothing seems to happen.
I can see the LED on the external drive blinking like h... and if I try to eject the disc I can't because it is busy.
Doing a fast refresh reveals that BC has indeed started copying files and does not seem to have in mind stopping to do so.
This is of course not so convenient and I see several issues here:
1) cancelling is not immediate - and if I pull out the disc without ejecting, I fear that it will be left in an undefined state, with regard to the files that appear to be copied.
2) There is no user info that tells the user what is going on and why the cancelling is not done.
I have been waiting (while writing this) for 30 min now, and (using fast refresh) I can see that 32 of 71 GB has been copied. I do not know whether the copy will proceed to the end or it will eventually stop.
I believe I have done this before and also used cancel. When the program finally cancelled the process (after copying a large amount of data), the copied data was deleted (which I guess is the correct handling of a cancel request - i.e. to leave thins as they were before the process (move in this case) was started. But then, why copy in the first place??
I can see in the process monitor that the unix command cp is running, and I suspect that BC is just using a system call to cp to first copy the folder and after that deleting the source folder (when moving). This would explain why BC can not halt the process. But I still think you should consider if this is the best way...
one more (general) thing: Why "Moving 1 of 1" when the folder contains numerous folders each with hundreds of files? I understand that only one folder is moved, but from the user standpoint it looks as if nothing happens until the entire folder and all sub items has been processed. I would suggest the text should rather be "Moving 1 of 1 folder (234 of 243662 files)" for instance.
Claus
PS: now at 44.4 GB of 71 GB after 45 min.
Comment