Community
Participate
Working Groups
On Local and FTP Moving a folder from one directory to another where the destination contains a folder by the same name as the one you are moving errors. Local Error Message: RSEF1307E: SUB#0:same --> same is the directory I copied FTP Error Message: RSEF1002E: SUB#0:550 Rename/move failure: Directory not empty --> Issue is b/c Delete on a folder that is not empty doesn't work DStore and SSH have different issue's and will be opening different bugs for those. -----------Enter bugs above this line----------- TM 2.0 Testing installation : eclipse-SDK-3.3 RSE install : RSE 2.0 java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
Assigning to Kevin to Fix Local -- that one should be simple since DStore works properly, and it should be possible to just re-use the DStore code (copy & paste will be necessary). Javier should look at the FTP issue -- I'm not sure if it can be fixed easily for FTP though since there are way fewer commands available. Javier Can you investigate?
I'll look into the issue for Local. Javier/Martin why does Delete not work if a folder is not empty for FTP? I've noticed this is how it works in other FTP Clients as well and it's such a pain to remove everything under a folder before deleting it. Is it to much work to recursively go through the subfolders/files and delete them before deleting the directory?
The FTP protocol does not support it, but I agree that recursive delete would be a great value-add for RSE. Kevin can you file an enhancement request for it?
(In reply to comment #2) > I'll look into the issue for Local. > > Javier/Martin why does Delete not work if a folder is not empty for FTP? I've > noticed this is how it works in other FTP Clients as well and it's such a pain > to remove everything under a folder before deleting it. Is it to much work to > recursively go through the subfolders/files and delete them before deleting the > directory? > From FTP protocol, it is not allowed. Issuing the command to delete a folder not empty should return an error. We could go for recursively deleting everything under that folder, but we have to agree in this behaviour, since it's not the standard FTP one.
If you look at the code for LocalFileService, the delete appears to be recursive via the deleteContents() call.
In FTP, moving a folder to another folder containing a subfolder with the same name doesn't seem to be allowed. Even when selecting "Overwrite" in the duplicate file dialog and issuing a RNFR + RNTO set of commands, the result is an error: 550 /eclipse/TargetManagement/test22/test: Cannot create a file when that file already exists.
I've opened bug #196351, for the discussion on recursive delete for ftp.
Created attachment 73699 [details] Move now just calls copy() and delete() Changed the code so no matter if the folder is virtual, archive, or just a normal folder they all perform copy() then a delete(). This is the same way DStore works. Legal Message: I, Kevin Doyle, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
Hm... the patch removes an optimization from local move which may be important: If you want to move a 500MB file from X to Y and you do so by copy-then-delete, you may run out of disk space whereas a real move operation would succeed. I would recommend the following approach instead - try the Java renameTo operation, and if it fails fall back to copy-then-delete. This is the kind of approach that the Eclipse EFS implementation also does in LocalFile.move() -- in fact LocalFile.move() does an additional check to see whether source.getCanonicalPath().equals(tgt.getCanonicalPath()). I think we should do that as well on Local. I think that the dstore implementation should also be changed to do what LocalFile.move() does and if it fails, fall back to the copy-then-delete approach just like LocalFile.move(). boolean movedOk = false; if (!sourceIsVirtual && !targetIsVirtual && !targetIsArchive) { movedOk = source.renameTo(tgt); } if (!movedOk) { if (copy(src, tgt)) { movedOk = delete(src); } } return movedOk;
(In reply to comment #6) > In FTP, moving a folder to another folder containing a subfolder with the same > name doesn't seem to be allowed. Even when selecting "Overwrite" in the > duplicate file dialog and issuing a RNFR + RNTO set of commands, the result is > an error: Provided that this error is properly displayed to the user, I'd be OK with keeping this functionality. Since we cannot easily merge the folders on an FTP-only connection, it's OK if the user must manually delete the target first (doing a recursive delete), then copy or move the source.
Created attachment 73745 [details] Try java File.renameTo if it returns false use copy/delete I've updated the patch, so it will try to use Java File.renameTo() and if it returns false we use copy/delete. File.renameTo() will return false whenever the destination exists. Legal Message: I, Kevin Doyle, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
(In reply to comment #10) > (In reply to comment #6) > > In FTP, moving a folder to another folder containing a subfolder with the same > > name doesn't seem to be allowed. Even when selecting "Overwrite" in the > > duplicate file dialog and issuing a RNFR + RNTO set of commands, the result is > > an error: > > Provided that this error is properly displayed to the user, I'd be OK with > keeping this functionality. Since we cannot easily merge the folders on an > FTP-only connection, it's OK if the user must manually delete the target first > (doing a recursive delete), then copy or move the source. > We get an error dialog, but the details message is related to the Directory not being empty, which doesn't say exactly why the Move failed. Error Dialog: Operation failed. File system input or output error Details: Message reported from file system: 550 Rename/move failure: Directory not empty It would be better if it reported that it didn't work as the destination contains a folder by the same name. It would be even better if the Duplicate Name Collision dialog didn't allow you to choose the Overwrite operation in this case.
Feel free to file a separate bug for that, but I'm OK with the current situation.
(In reply to comment #13) > Feel free to file a separate bug for that, but I'm OK with the current > situation. > I've opened up Bug 196471 for this issue.
Created attachment 73857 [details] Updates for Local and DStore move to use Java File.rename() Dave, I've changed how DStoreFileService.rename(...) works a bit. If you pass an emptry string or null parent then it will take the oldName and newName to be the full paths of the old and new renamed files. This way we can use Java file.renameTo in the UniversalFileSystemMiner.handleRename(...) with the 1 line change in it. What do you think? Anything that should be changed? Legal Message: I, Kevin Doyle, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
I'm okay with this. I've committed the patch to cvs.
Verified with I20070719-1300.
