When copying a single file from the root of a zip file to the root of another zip file, the target zip file
doesn't automatically refresh after the copy operation
contains the new file not in the root, but instead in a subfolder structure that is a copy of the FULL PATH of the source zip files location in the file system down from the drive letter, e.g.
When copying from c:\backup\somefolder\someotherfolder\source.zip\myfile to d:\myfolder\target.zip\
The target ends up here:
myfolder\target.zip\backup\somefolder\someotherfolder\myfile
On top of that, if myfile already exists in the target zipfiles' root, dopus complains about "replace/skip" even though it never replaces the file, instead it puts it in that subfolder structure anyways.
Nope, all I use is the standard copy command button. It gives me a much smaller window without a "save full file paths" option, as it should, since my copy wish is unambigous -> it should behave like any other copy operation in a dual lister and copy the file from source to target.
This should be easily reproducible.
I am attaching two images showing the sequence.
I click the copy as button and get the dialog shown in picture 1
Afterwards a requester pops up asking for the new name and I enter one.
If I use copy instead of copy as to begin with, a name conflict pops up allowing me to choose replace/skip.
Then, eventually I arrive at picture 2. Note that to get to picture 2 after the copy operation, I had to refresh BOTH dual displays (e.g. click on the left, click refresh, click on the right, click refresh). The delme2 path does not show up without refreshing. The full path is now in the zip file with a subfolder named neogeo.zip (which is a folder not a zip), and in there is the file with the correct new name.
There are three things wrong with this hinting at three separate bugs concerning copying between zip files:
Dopus is asking about a non-existing name conflict (since it creates subdirs there is no conflict). Hence I used copy as to keep going.
Dopus is creating subdirectories in the target when it shouldn't
Dopus is neither refreshing the target nor the source
I think if these real bugs in zip handling can be ironed out, at least it will become much less of a headache.
I have to say I love Dopus, but I have been fighting with the inconsistent zip handling since what feels like forever now. I am not sure how it could be completely fixed without a complete paradigm shift to treating archives truly as folders. I have a similar headache with sub-collections not being treated as folders.
A quick example of a recent headache with zips: How do I sort a list of archives by "uncompressed" size? When I click size it shows me the archive size, but I want to know the uncompressed size! I cannot find a column for that, but maybe I could program my own somehow. Since it can sort by Mp3 track no., why not by uncompressed archive size? So I keep uncompressing and re-compressing for no reason.
I have also seen several other instances of Dopus not refreshing a) filters, b) directory size numbers, c) updated files in listers when copying to USB sticks mostly. But those I might file in other reports.
Can you reproduce this effect if you start a new zip file from scratch? I just tried it here and wasn't able to get it to happen.
(as an aside, you originally said you were copying from one zip file to another, but in your above screenshot it looks like you're trying to copy from a zip file into itself)
If you turn off Preferences / Zip & Other Archives / Zip Files / Ask for encryption/compression settings when copying into Zip files does it still happen?
