Summary: | Undoing a copy operation might delete a modified file causing loss of data. | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | tommasopaba |
Component: | general | Assignee: | David Faure <faure> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, hausmann, yuriy.kozlov |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | RedHat Enterprise Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
tommasopaba
2001-02-16 00:35:15 UTC
I can confirm this bug for konqueror 2.2.1 (RH 7.2) Having a modified file copied to a different location does not result in loss of data. However the following does: * drag-and-drop copy a file to a new location (or the same location with a new name) * modify the copied file in an external editor * ctrl-z (Undo) in konqueror --> modified file go bye-bye! ACK. It's hard (if not impossible) to fix for cut though. The only way I see to fix this for cut is to save a hash of the file. and the fire up a messagebox then in case there is a mismatch when pasting you mean? Confirmed for copy/undo in CVS HEAD from 5.11.03 Confirmed for KDE 3.3.0, Konqueror 3.3. Wiped out 2 days worth of work! =) Thanks for all the hard work! 2 days is a small price to pay for progress! =) i can still verify this bug in current CVS HEAD (pre-3.4beta2) Since this bug can cause data loss, doesn't it deserve a higher severity? Related problem: Undoing a "create new -> file -> text file" (or similar) operation will delete the file even if modified with an external editor in between. Results in loss of data. Proposal: you could provide redo functionality or throw the file in the trash instead of deleting it. konqueror is high quality software anyway :) *** Bug 140218 has been marked as a duplicate of this bug. *** SVN commit 626835 by dfaure: Fixed 6-years old bug 20532: Undoing a copy operation might delete a modified file causing loss of data. A confirmation message box is shown when undoing a copy after modifying the file [this relies on copy preserving the mtime though, which might not be true for all protocols but we'll have to fix that]. The less severe case of move, modify, undo (no data loss, but the modified file is moved back) can't be fixed in all cases, since moving a whole directory can be done by a simple rename() call, so we have no information on all the files inside the directory. For single files it could be done though, but that's not implemented by this. BUG: 20532 M +2 -2 kdebase/libkonq/konq_operations.cc M +275 -212 kdebase/libkonq/konq_undo.cc M +28 -5 kdebase/libkonq/konq_undo.h M +30 -23 kdebase/libkonq/konq_undo_p.h M +64 -17 kdebase/libkonq/tests/konqundomanagertest.cpp M +6 -2 kdebase/libkonq/tests/konqundomanagertest.h M +3 -5 kdebase/workspace/kcontrol/kfontinst/kcmfontinst/KCmFontInst.cpp M +1 -1 kdebase/workspace/kcontrol/kfontinst/kcmfontinst/KCmFontInst.h M +7 -6 kdelibs/kio/kio/copyjob.cpp M +3 -1 kdelibs/kio/kio/copyjob.h |