Two scenarios here, one being critical. Both result in a local file being deleted when copying to an FTP server. The problem only occurs when using a RMB drag/drop and selecting "Copy" from the context menu. Using a command button Copy operation works as expected. In both cases I'm using a dual pane lister with the FTP site on the left and local file system on the right.
Anonymous FTP account
I created an anonymous FTP account on my server that is read only. To test that it was working properly I tried a file drag/drop copy to the target FTP lister pane and received a DO error dialog indicating that the file could not be found (see attached image). Selecting Skip or Abort resulted in the file disappearing from the source lister. I verified that the file was actually deleted by refreshing the lister and then attempted an Undo operation to retrieve it. Instead of restoring it, DO generated a "Confirm Delete" dialog asking if I wanted to really delete the file. This makes absolutely no sense as the file was already gone. I then tried opening the Undo dialog to see what was in the queue and after a short busy cursor nothing happened. The Undo dialog would not open.
Full access FTP account
In this case the file was copied as expected to the FTP server on a drag/drop operation but then subsequently deleted from the local file system with no confirmation or error messages. Attempting an Undo resulted in the same "Confirm Delete" dialog as in the anonymous FTP case.
The anonymous case is critical. The data does not get recycled and is permanently lost.
This doesn't really make sense because the FTP drag and drop menu is hard-coded to just 'copy' or 'move', and should be exactly the same as the toolbar buttons. If you're selecting 'copy' then there should be no reason the original file is touched in any way.
A couple of us have just tried this here and can't reproduce it. Can you share the details of the FTP server involved? Maybe it's something specific to that server.
I understand. This doesn't make much sense to me either. I'm running a full virus scan right now to make sure DO isn't being compromised by something else. I've also been experiencing DO freezing up on a consistent basis (see [DO 9.0.0.6 Freeze Requires Reboot)) so something in my system is really screwed up. If I can rule DO out of the picture that would help me narrow this thing down (incompatible/corrupt system dll's etc.)
I understand. This doesn't make much sense to me either....
My FTP site is ftp.ingenosity.com. Login anonymous@ingenosity.com with any password. The account is read only.
[/quote]
Maynard,
This is simply not possible. I've absolutely no idea what you are seeing here but it is not being done by Opus as you describe. Notwithstanding my knowledge, I did reconfirm this by trying what you have suggested and there were no problems. The copy simply failed with a dialog for the 553 error .
What you describe simply cannot happen unless you have specifically deleted the local file. The copy for the FTP is a completely separate process to any action on the local file. A file COPY action to FTP can not delete nor change the local file in any way. A File MOVE action to an FTP site can only execute the subsequent delete or the local file if the file copy function to the FTP site succeeded.
In all cases with this site, the FTP copy fails and this is the end of the function.
The only theoretical way for such an action as you describe would be if you manually did two operations - a copy followed by a manual delete action.
Feel free to email me directly if you have any further information.
