Version: 3.3.0-8 (using KDE KDE 3.3.1) OS: Linux When performing a copy/move with multiple files selected, an operation should NEVER fail in the middle due to a problem with one specific file. Currently, a whole range of problems, such as permissions, file access or file type (trying to copy a socket, etc.) will cause an error dialog box to appear, and will abort the entire process. This is EXTREMELY frustrating since there is no way to know how many files were copied, and how many were not yet copied, at the time of the failure. It should not be necessary to abort an entire process due to a problem that affects only a single file. In fact, this is exactly what Microsoft Windows File Explorer does... Instead, the operation should continue until all selected files have been copied/moved. Then, at the end a summary can be presented, saying "The following files could not be copied/moved because...." This way, even if a few files cause problems, the operation can still be completed.
Oh yeah, I can forsee "Your hard drive is full - so these files could not be copied: <1000> files". I don't think this makes sense. If something is wrong, you better stop if you have no idea what's going on.
But you shouldn't have NO IDEA what is going on, after all you do get an error from the file system. And there are some events which let you decide what you want to do, like if the destination file exists. The point is that right now the process dies for every single little problem, even if it applies to just one file, then you're completely screwed...you don't know how far you've got and you can't fix the problem and restart. So, if you're afraid of the potential for those "1000 files" then why not display a dialog..."Do you want to continue processing the rest of the files?" Then the user can decide based on the actual error to cancel if it's obviously a problem (like disk full) that affects most or all of the files.
*** Bug 102040 has been marked as a duplicate of this bug. ***
I think the "do you want to continue processing the rest of the files?" idea is the best solution. It should have options like "Continue," "Cancel," and "Continue even if more errors occur." (The "Continue" option would continue until another error occurs, the "Continue even if more errors occur" option would continue regardless of additional errors, without asking again).
*** Bug 116769 has been marked as a duplicate of this bug. ***
The "Continue" option should allow you to retry the current file. Maybe "Retry" is better. Many times I go and delete some stuff in the middle of a copy and just want to continue
*** This bug has been confirmed by popular vote. ***
*** Bug 76240 has been marked as a duplicate of this bug. ***
I still think it's no good. As it is, I have to use something like GNU Midnight Commander (sometimes with fuse_kio) so that things like "Could not copy: Access Denied" won't stop a five-hour file copy half-way through while I'm AFK expecting it to complete by the time I get home. Something's definitely wrong when the user ends up using a different tool to get the job done.
Konqueror should continue processing what it can, until the user answers the dialog. I have also had situations where a three-hour operation was held up because I _thought_ that konqi was working when there was a dialog about an error. This is not only annoying, it cuts into productivity and makes the application look like it was never tested in real-life situations.
[Updating the title to the better one from bug 212077]
*** Bug 212077 has been marked as a duplicate of this bug. ***
*** Bug 276535 has been marked as a duplicate of this bug. ***
A more intelligent handling would make sence. Based on the warning / error, the system must decide wheather to continue to copy / move or not. Example: Drive-full means: No sence to copy, stop it and wait for user action. File-already-existing means: Copy everything that doesn't exist yet WHILE displaying the message, because it's obvious that in all cases, the user wants those other non-duplicate files to be copied. If one duplicate file of 50K holds up the process for 2000 files with 500G, that's annoying! The bug was started in 2004. I would like to incicate that nowadays, the described system is ALREADY IN USE: For example in Windows 7.
There is currently a GSOC project working on fixing this (amongst other things). As you suggest, a more error-specific approach is needed, and that is the goal of that part of the project. Here is a link to the project: http://www.google-melange.com/gsoc/project/google/gsoc2011/munk/13001
Great inputs there. There's 3 new things to do that would be very smart. Hope, all those ideas will one day be combined.
I think this is fixed with the progress of the GSOC project so far.
*** Bug 325336 has been marked as a duplicate of this bug. ***
*** Bug 345153 has been marked as a duplicate of this bug. ***
*** Bug 303865 has been marked as a duplicate of this bug. ***
*** Bug 55111 has been marked as a duplicate of this bug. ***
*** Bug 404153 has been marked as a duplicate of this bug. ***
*** Bug 408327 has been marked as a duplicate of this bug. ***
Just had this problem. Long file transfer over night. Expected it to be finished by the morning, but it stopped the whole transfer because there was a "could not copy" dialogue with "cancel, retry, ignore, auto-ignore" I think the solution could be to at least add an option that always ignores errors but opens a scrollable dialogue with all the problematic files and why they failed.