Results 1 to 5 of 5
  1. #1
    Join Date
    Feb 2008
    Location
    Lynge, Denmark
    Posts
    113

    Default Bug: FC: cancelling operations does not happen instantaneously

    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.

  2. #2
    Join Date
    Feb 2008
    Location
    Lynge, Denmark
    Posts
    113

    Default

    update: BC completed the move in about an hour, despite that I cancelled.

  3. #3
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,949

    Default

    When the Cancel or Abort buttons are used, BC3 sends the signal to stop the transfer. However, we have to wait until we receive a response back from the device to complete the abort. A similar scenario I've seen in the past is a network device that has a very long time-out period, and refused a cancel until that period has expired (usually minutes). If you are copying from a server to an external device, could you try a similar transfer involving only one of those devices (server to local harddrive, and local harddrive to external)? This would help narrow down which part of the transfer is the one ignoring the abort command. If you can find this, I would recommend checking to see if there are newer drivers or firmware available for that device, to see if this is an issue that has already been fixed.
    Aaron P Scooter Software

  4. #4
    Join Date
    Feb 2008
    Location
    Lynge, Denmark
    Posts
    113

    Default

    The server-external drive was a typical example. What I experienced today was actually a move from the local harddrive to an external harddisk (WD MyBook Essentials 3.TB).

    I will try (later) to move from one local folder to another local folder and cancel immediately after starting the move - and report my finding.

  5. #5
    Join Date
    Feb 2008
    Location
    Lynge, Denmark
    Posts
    113

    Default

    Finally got around to test the current beta. The bug reported in this thread is fixed. Thanks!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •