Not sure if you take feature requests here, or if this can be solved by an alternative means. I did search, but my combination of terms may not have been clear enough...
If a filename exists within an archive, and a new file with the same filename is added to the archive (in a
or u
mode), the existing file is often overwritten. There is a -u
flag which accepts a matrix of options which controls when this happens.
However, I would like to be able to keep both the existing compressed file, and add the new file but have one or the other auto-renamed. While the rn
mode does already exist, it can be somewhat tortuous from within batch-scripting to examine the existing archive, rename all the files that exist and then compress new files, and I am wondering if it is something you might consider extending the existing command-line to be able to do.
From a user-interface perspective, I can see one of two ways how I might indicate this to the 7z.exe
command-line:
-u
switch to accept new action values 4
and 5
; where 4
copies the existing compressed files with a new name (and compresses the on-disk file with the existing name), and 5
copies the existing compressed files with the existing name (and compresses the on-disk file with a new name)-ao
switch to also work under a
and u
modes; where -aou
adds the on-disk file with a new name (and copies existing compressed files with the existing name), and -aot
copies the existing compressed files with new names (and compresses the on-disk file with the existing name) The other two options, -aoa
and -aos
, could still also be used to mean overwrite and skip, as the do currently.Which of these would be easier to implement would, of course, be for you to decide.
The existing auto-rename naming algorithm is fine -- I don't believe there would be any requirement to differ from it.
For example, if on disk, there was:
alpha.txt
beta.gif
gamma.bin
...and in the archive, there was:
alpha.txt
...then, by invoking either of 7z a -up1q1r2x4y4z4w4 arch.7z *
or 7z a -aot arch.7z *
(your choice), you would end up with the archive containing:
alpha.txt <-- the new on-disk file
alpha_1.txt <-- the existing file
beta.gif
gamma.bin
If it were infeasible to offer a choice of which file to rename, then just allowing for one of them to be renamed (and documenting which one that would be) would be entirely acceptable. If in doubt, I suspect auto-renaming the newly-added file might be the easier option.
What are your thoughts?
Maybe you want deduplication in archive, like in zpaq/zpaqfranz?
Not quite what I'm after for this particular issue, but definitely an application to look further into...