Question about QuickBMS's r function for renaming duplicate files.

[Graesholt]

Hey, fairly new to all this.

I was unpacking a bunch of .ARCH05 archives from Shadow of Mordor (Using New_Fear.bms) and wanted to keep duplicate files. So when the dialog (or whatever you call that. Prompt?) came up, I pressed r, to have quickbms automatically rename duplicate files.
However, this landed me with a bunch of duplicate files with 0000000x at the end of their names, and NO file size.

I have looked through this document, which was all I found on google, and cannot quite decide if this is the intended behaviour of this function.
Does the zero file size mean that there is zero diference between the first file and the duplicate?
And in that case, what does QuickBMS do if there is a difference - does it store a file with only the difference?

I'm certain theres a system to all this, but I am a little confused...

[aluigi]

You get zero-sized files because they have no size. The renaming feature is not involved in that.

[Graesholt]

You get zero-sized files because they have no size. The renaming feature is not involved in that.

I have fiddled around with the goal of understanding, and you appear to be quite correct.
As always, sorry for the rudimentary questions, and thank you for prompt support!

[aluigi]

When you see something weird like may zeroed files remember to check the final value displayed by quickbms: "coverage file 0 " followed by a percentage.
If that % is bigger than 95% then it's all ok.
Remember that the coverage depends by the format, in some formats you can have a coverage of 100% while in others even 70% (small file and lot of padding) and both are correct.

[Graesholt]

When you see something weird like may zeroed files remember to check the final value displayed by quickbms: "coverage file 0 " followed by a percentage.
If that % is bigger than 95% then it's all ok.
Remember that the coverage depends by the format, in some formats you can have a coverage of 100% while in others even 70% (small file and lot of padding) and both are correct.

I'm not sure that I understand this completely after running a second test.

When unpacked seperately using New_Fear.bms, two files, hosted here (sorry for size, they don't come smaller), will each produce an instance of the example file:
[Export Directory]\model\weapons\player_weapons\player_sword01\player_sword01_d.tex0
both have a size of 4.097 KB

However, when exported together, and hitting r when prompted, the files will produce two files in the same location: Good old player_sword01_d.tex0 and a second file player_sword01_d_00000001.tex0
The first has a size of 8.193 KB and the second has a size of 0 KB

Once again, sorry if I keep asking stupid questions, but I don't understand, is this the intended behaviour?

[aluigi]

Even without downloading the sample I think I understand what's happening.

I bet the samples have a "LTAR" magic at their beginning (you can check it with a hex editor), that means it uses the append mode with the compressed files, so it creates an empty file which already exists (it was generated by the previous archive) and you choose 'r' so this empty file will have the _00000000 suffix, then it will append the various chunks of the file but the output is the original filename and not the new _00000000.
Result: the old file contains both the old and new file while the new _00000000 file is still the empty one.

I have not checked the source code yet but I bet this is the bug, I will check and fix it in the next version of quickbms.
Good catch

Now, back to the original problem, you must use the -d option to handle multiple files from the command-line.
As far as I remember, from the GUI (double-click on quickbms.exe) when you select multiple input files the output files will be placed in a folder having the name of the input.
In command-line mode that doesn't happen by default and you have to specify this -d or -D option to do that, so you will no longer have duplicate files.

[aluigi]

Ah, regarding -d and -D.

Very quickly:
if you have many input files placed in various sub-folders, use -D
if you have some input files placed just in the same folder, use -d

[Graesholt]

Even without downloading the sample I think I understand what's happening.

I bet the samples have a "LTAR" magic at their beginning (you can check it with a hex editor), that means it uses the append mode with the compressed files, so it creates an empty file which already exists (it was generated by the previous archive) and you choose 'r' so this empty file will have the _00000000 suffix, then it will append the various chunks of the file but the output is the original filename and not the new _00000000.
Result: the old file contains both the old and new file while the new _00000000 file is still the empty one.

I have not checked the source code yet but I bet this is the bug, I will check and fix it in the next version of quickbms.
Good catch

Now, back to the original problem, you must use the -d option to handle multiple files from the command-line.
As far as I remember, from the GUI (double-click on quickbms.exe) when you select multiple input files the output files will be placed in a folder having the name of the input.
In command-line mode that doesn't happen by default and you have to specify this -d or -D option to do that, so you will no longer have duplicate files.

Ah, regarding -d and -D.

Very quickly:
if you have many input files placed in various sub-folders, use -D
if you have some input files placed just in the same folder, use -d

Alright, this works great.
Thanks again (: