Umm @Aditya30ag , Before proceeding with testing this pull request, I would like to address a couple of points. Firstly, thank you for providing such a detailed description. Secondly, regarding the screenshot you posted that shows files being exempted and the ununpack agent working correctly, is this part of a test suite you have developed? If so, such a level of testing would be highly appreciated in ununpack test suite.

Otherwise, don't you think uploading and testing a component (specifically hwloc-2.9.3.tar.bz2) through the UI or REST API might have been more practical?

Thank you @Kaushl2208 for the detailed feedback and for appreciating the comprehensive description!
Regarding the test suite question:
You're absolutely right - the testing I showed in the screenshot is from a custom test program I created to validate the fix. It's not currently part of the formal ununpack test suite, but I'd be very happy to integrate it!
I created a standalone test program that:
Tests the specific problematic file paths from issue #3082
Verifies that legitimate archive files are still processed correctly
Validates the filtering logic works as expected

I can absolutely convert this into a proper test case for the ununpack test suite. Would you prefer:
A unit test that directly tests the FindCmd() function with the problematic file paths?
An integration test that processes a sample archive containing system files?
Both approaches for comprehensive coverage?
Regarding UI/REST API testing:
You make an excellent point about practical testing. I did test the fix with the actual hwloc-2.9.3.tar.bz2 file locally, and it resolved the crashes. However, you're right that demonstrating this through the UI or REST API would be more practical and representative of real-world usage.

Hey @Aditya30ag,

Thanks for addressing the issue and putting together a thorough set of filters. I reviewed the changes, and while the solution effectively targets the immediate problem preventing system files (e.g., /sys/firmware/dmi/entries/*, etc.) from being misinterpreted as archives, I have a few thoughts from a long-term maintainability and extensibility standpoint.

The current approach adds a growing list of hardcoded paths and filename patterns to be excluded. While this solves the specific case raised in the issue, it introduces a maintenance concern. Filesystem structures and dump contents can vary widely across distributions and tools. Relying on static string matching (e.g., /sys/, /proc/, file name substrings like board_, etc.) creates a slippery slope we’ll likely encounter new cases that require yet another round of patching.

In fact, PR #3087 addresses this more generically by introducing user-configurable exclusion logic. This gives users control over what should or shouldn’t be unpacked based on their context, and helps prevent us from encoding every possible edge case directly into the codebase.

Appreciate your work on this. Let’s aim for a solution that not only resolves this issue but also scales better as the variety of archive contents continues to grow.

CC: @shaheemazmalmmd

Hey @Kaushl2208 ,

Thanks for the detailed feedback and for reviewing the changes so thoroughly. You raise a very valid point about the long-term maintainability concerns of relying on hardcoded path and filename filters.

The solution I proposed was indeed targeted to resolve the immediate issue at hand by explicitly preventing known problematic system paths (like /sys/firmware/dmi/entries/*) from being misinterpreted and unpacked. However, I completely agree that this approach can become unsustainable over time as we encounter new edge cases across different environments and distributions.

You're absolutely right that PR #3087 takes a more scalable and extensible direction by introducing user-configurable exclusion logic. That approach empowers users to tailor unpacking behavior to their specific needs, without us having to continuously expand hardcoded rules in the codebase.

I'm aligned with the broader goal of building a robust and adaptable solution. If the team is in favor, I’m happy to pivot this effort toward supporting or refining the logic introduced in PR #3087, and perhaps merging in the path-specific filters as default configurations or examples rather than enforcing them in code.

Appreciate your insights — this kind of collaborative thinking really helps us move toward cleaner and more future-proof solutions.