Open brian6932 opened 4 months ago
@brian6932 I suspect this is because there are two of these files in that msi. After extracting them I ran the following commands to see the files:
C:\Users\scott\Downloads>dir /s AppleMobileDeviceSupport64\SourceDir | findstr libcache.dll
11/08/2023 04:37 PM 37,688 libcache.dll
11/08/2023 04:31 PM 45,880 libcache.dll.duplicate1
That .duplicate1
extension is added by lessmsi when it detects it is extracting a file into athe same place. Just guessing, but maybe they have x32 x64 versions in there and the lessmsi logic extracts only one based on the target OS.
You can also open that msi up in the GUI and do a Ctrl+F fr libcache.dll and you'll see both of them there too:
I'm closing this issue with the assumption that gets you straightened out, but if not, feel free to re-open or open another issue.
You're right about the duplicates being the right sizes, but msiexec doesn't do this. I'd wager there's some way you can tell which dll is for which platform, or some flag should be added to choose the largest duplicate, storing a bunch of sizes in a table isn't a modular approach to this, and it doesn't make a ton of sense to extract 2x the data I actually need.
Well I don't think those bits are being mangled, but I suspect there is some heuristic that could be used to fix the paths. When I was looking at this yesterday I noticed they were linked to two different install directories with a 64
or 32
in the names. Looking at the Directory table closer now I see these two files ultimately resolve to a directory named CommonFiles64Folder
and CommonFilesFolder
that have the same default value of Common Files
. Which is where it gets put and one overwrites the other.
I suppose we could implement some logic in lessmsi to detect at least those root-level duplicate directory names (root level == TARGETDIR
per https://learn.microsoft.com/en-us/windows/win32/msi/directory-table#remarks) and differentiate them somehow like Common Files-CommonFiles64Folder
and Common Files-CommonFilesFolder
or something.
Would that meet your needs?
P.S. Some of this is a bit of a note to myself :)
Yea SGTM
Hello @activescott @brian6932
I found a way to differentiate between 32 bit and 64 bit dll files, regardless of their name or file path.
@brian6932 what would be the best outcome for you?
Would you like LessMSI CLI to extract only the files relevant to your system? I.e. ignoring any 32bit files where your system is 64 bit and vice versa.
Or would you like to preserve the ability to extract all the files using a designated flag?
Thank you.
Would you like LessMSI CLI to extract only the files relevant to your system? I.e. ignoring any 32bit files where your system is 64 bit and vice versa.
Imo, yes when a duplicate filename exists as the default behavior, but there should be flags to alter it, and maybe one to ignore altogether (e.g. -a <arch>
, --architecture <arch>
, --ignore-architectre
).
Great, what is the way to differentiate? Will it work with all msi's?
Agree with the flag.
What if someone wants both versions? Would they do the extraction twice (which is probably fine)?
@activescott, using the PEHeader Magic property I can easily check if a PE file (dll, exe and so on) is 32 or 64 bit.
IMO x
command should yield both versions, as there are scripts using LessMSI which expect this kind of behaviour.
If the user would like to get the 64 bit files, they can run the next command:
lessmsi.exe x path/to/msi -a=64
And so on for the 32 bit. Thoughts?
Sounds good. Let's try it!
@activescott Can you please assign this ticket to me?
I think this ticket and the overwrite ticket are related and can be solved together by one update.
Assigned to you. I was thinking that it is possible the original issue that I described above will still need solved in addition to doing the architecture flag - as some files might turn out to be duplicates that are not DLLs. I'm not positive that would happen but it seems plausible. Anyway, I think the architecture flag is still a great idea though so we should start there.
Describe the bug https://i.alienpls.org/AppleMobileDeviceSupport64.msi
The following DLLs are required, for the service to run (these are the expected sizes, from an msi install)
Out of those, from just looking at byte lengths, (these are broken, extracted by lessmsi)
To Reproduce
Expected behavior Should work.
Desktop: