Changeset 5719 for trunk

Timestamp:

2003-10-23T11:05:18+13:00 (21 years ago)

Author:

jmt12

Message:

Fixed little bug where not overwriting a file caused the progress bar to become inconsistant. Also commented out undo file movement code since undo isn't supported at the moment

File:

• trunk/gli/src/org/greenstone/gatherer/file/FileQueue.java (modified) (7 diffs)

trunk/gli/src/org/greenstone/gatherer/file/FileQueue.java

@@ -259 +259 @@
                     break;
                 case 3: // No To All
-                    cancel_action = true;
+                   cancel_action = true;
                 case 2: // No
                 default:
-                    ready = false;
+                   ready = false;
+                   // Increment progress by size of potentially copied file
+                   progress.addValue(origin_node.getFile().length());
                 }
                 }
@@ -467 +469 @@
                 }
                 else {
-                metadatum= Gatherer.c_man.getCollection().gdm.removeMetadata(origin_node.getFile());
-                }
-                // determine it parent node
+                metadatum = Gatherer.c_man.getCollection().gdm.removeMetadata(origin_node.getFile());
+                }
+                // determine its parent node
                 FileNode parent_record = (FileNode)origin_node.getParent();
                 // Remove from model
@@ -477 +479 @@
                 FileNode recycled_parent = null;
                 if(job.type == FileJob.DELETE) {
+
+                   /** If we ever decide to reenable undo then this code will have to be seriously improved.
                 // See if this record already has a previous recycle folder noted in the recycle folder mappings.
                 recycled_parent = (FileNode) recycle_folder_mappings.get(origin_node);
@@ -506 +510 @@
                 }
                 Gatherer.c_man.undo.addMetadata(source_file, metadatum);
+                   **/
                 }
                 // delete the source file
                 Utility.delete(source_file);
+                /**
                 // create undo job as necessary. File move would have been handled above.
                 if(job.undoable) {
@@ -517 +523 @@
                 recycled_parent = null;
                 recycled_file = null;
+                **/
                 //metadatum = null;
             }
@@ -526 +533 @@
                 // Don't worry about all this for true file move actions.
                 if(job.type == FileJob.DELETE) {
+                   /** Again, if we reenable undo then this code must be debugged.
                 // See if this record already has a previous recycle folder noted in the recycle folder mappings.
                 FileNode parent = (FileNode) recycle_folder_mappings.get(origin_node);
@@ -557 +565 @@
                     recycle_folder_mappings.put(child_record, recycle_folder_record);
                     }
-                }
+                    }
+                   **/
                 }
                 // Requeue a delete job -after- the children have been dealt with. Remember I've reversed the direction of the queue so sooner is later. Te-he. Also have to remember that we have have followed this path to get here for a move job: Copy Directory -> Queue Child Files -> Delete Directory (must occur after child files) -> Queue Directory.