Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract files w/out paths? #174

Open
STaRDoGG opened this issue Feb 9, 2022 · 6 comments
Open

Extract files w/out paths? #174

STaRDoGG opened this issue Feb 9, 2022 · 6 comments
Assignees

Comments

@STaRDoGG
Copy link

STaRDoGG commented Feb 9, 2022

Is there a way to just extract the files themselves, without lessmsi also re-creating the folder paths inside the msi?

i.e. I extract to the path C:\blah\, (lessmsi.exe x "{file}" C:\blah\) and all files get extracted by themselves into that folder, rather than say extracted like: C:\blah\SourceDir\Something\<the files>

@mega5800
Copy link
Contributor

mega5800 commented May 6, 2024

Hello @STaRDoGG and @activescott

I started examining your request and believe such feature can be added to the CLI.
I would like to present the next solution and to make sure that I am fully covering your use case.

To support this feature, I'd like to introduce a new CLI parameter called "xf”, which will extract the MSI files in a flat way, without the folder structure, as you requested.
The name consists of "x" (the original command for extraction) and "f" which stands for flat.

This command will run a regular extraction command for the given MSI file and a temp folder, which will hold the yielded files and their folder structure.
The next step would be to copy only the files from the temp folder to the original destination folder.
After the copy is done, the temp folder will be deleted.
Finally, you, as the user, will get the only the MSI files without any folder structure.

Would love to hear your opinion about this approach.

Thank you.

@activescott
Copy link
Owner

I support this general appraoch of using a temp folder. I do think it is important that we account for those .msi files that have files in them with the same name, but from two different directories. These is even the root cause of an issue recently in #187 . Therefore, I suggest to include a test on an msi that has two files with the same name in two different directories. Which file will be in the flattened directory?

@STaRDoGG I'm curious since you reported this... What do you expect lessmsi to do when two of the files in the msi have the same name (but different folder)?

@mega5800
Copy link
Contributor

mega5800 commented May 8, 2024

@activescott, I totally agree wth your comment regarding files with the same name in different folders.
I will check this case during the day.
Thank you.

@STaRDoGG
Copy link
Author

Thanks for getting to this, guys. I'm just now logging in and seeing this thread update.

Re: duplicate file names, perhaps just go with the standard and most intuitive way; the options:

a). ask to overwrite
b). ask to rename

In the case of renaming, the renamed file can have whatever makes the most sense; maybe just the usual file name (1).ext, (2), (etc.), or maybe append the path to the name, something like file name - <path it would've gone into>.ext (which obv has the potential to get kinda long, if that matters).

Also, maybe a flag or 2 to auto-do one of the above to not annoy the ones who don't want to be annoyed with questions.

something like:

overwrite: -xfo
rename: -xfr

Just my 2¢

@mega5800
Copy link
Contributor

@STaRDoGG, thank you for your valuable suggestions, they make sense in terms of usage in my opinion.

@activescott, please let me know what do you think about the suggested functionality.
If you're happy, I will start working on implementing this feature and hopefully will have some results in the following two weeks

@activescott
Copy link
Owner

@mega5800 I'm fine with these suggestions of using some command line options to do the rename or overwrite. I don't have a strong opinion about the name chosen for the renamed file. I'd do the simplest thing.

I don't think we're suggesting this, but lets avoid a "prompt" in an CLI that will wait for input, because if someone attempts to automate the CLI in a script those prompts can be a nasty surprise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants