libewf-Linux-x64.so hardcoded location...

[alicektx]

Hi - first let me thank you for your wonderful work here, makes life way much easier...

There's some kind of hardcoding currently going on in regards to where it's loaded from... it's looking for it under libs/x64. On the 'binary' release, right after extracting, with libs/x64 subdirectories being there, libewf-Linux-x64.so gets loaded just fine.

The deb though instead creates: /usr/lib/quickhash/x64/libewf-Linux-x64.so Hence it doesn't get loaded and the E01 feature doesn't work as intended... (LD_PRELOAD didn't worked either). Quick workaround...by creating and moving such instead to: /usr/lib/quickhash/libs/x64/libewf-Linux-x64.so

Still, that's quite a bit of a 'weird' and rather long / convoluted path in my humble opinion... Maybe it would be better to simply dl-open it from within the same folder the quickhash resides... or else say just from a single subfolder / shorter path or something (less sub-directories, and less issues...)

Not into forensics myself (ie. i really don't have a need for E01 support myself), but hey...since it was included, i did gave it a quick run if nothing else out of curiosity... :-)

All the best

[darealshinji]

Yeah, the Makefile needs to be adjusted to install it into the right path. I agree however, no need for the subdirectories.

[tedsmith]

The package building came a little later than we hoped so there was a bit of last minute tweaking here and there.

I did, however, test it on a Linux mint virtual machine and it installed and worked ok for me. The library loaded ok. Which is puzzling me, now, reading your post. I'll have to go and look over it again. I made some changes of my own to the makefile but darealshinji has I think improved it further .

Nevertheless we have since made tweaks and I need to rebuild the package when I get chance. Thanks for reporting it nevertheless.

As for the need for subfolders...I guess it does indeed seem unnecessary for one architecture of one OS. But, during development, I had 7 DllS for Windows, 1 SO for Linux, plus sqlite to think about, plus libraries that ship natively in Linux and OSX and the respective versions that come with them. for both 32 and 64 but systems in a cross platform sense. So to me I do think it makes sense to keep them in a folder structure rather than dumping them all in the root. In fact, when I first added sqlite folks moaned to me that a 32 bit dll was shipped with the 64 but version and a 64 bit dll was shipped with 32 bit, just because I shipped both DLLS in the root. So this was an attempt at arranging it a bit better for cross compilation and cross architecture . Sure there are probably better ways of managing this but I have a lot to think about when creating a release and this was a first attempt at managing them.

[alicektx]

Hi Ted, here's what i did step-by-step...i first grabbed a small sample E01 image from here: ubnist1.casper-rw.gen0.E01 File - Select File (with SHA1) - ubnist1.casper-rw.gen0.E01 A handy pop-up helper asks, "Hash Full E01" or "Hash E01 segment only". With the deb, for "Hash Full E01", it instantly said 'Hashing Complete" (but no hash was calculated whatsoever). "Hash E01 segment only" worked correctly though. That's how it came up to me initially that something must have been slightly off there.

...to be perfectly honest as well: the way that you currently handle it (with all the executable files residing under /usr/lib/programname/), actually reminded me almost instantly of how p7zip-full is packaged: /usr/lib/p7zip /usr/lib/p7zip/7z /usr/lib/p7zip/7za /usr/lib/p7zip/7z.so /usr/lib/p7zip/7zCon.sfx With the extra p7zip-rar package (to get the bonus unrar plugin module), you then get one extra subfolder there, and the dir structure becomes... /usr/lib/p7zip /usr/lib/p7zip/7z /usr/lib/p7zip/7za /usr/lib/p7zip/7z.so /usr/lib/p7zip/7zCon.sfx /usr/lib/p7zip/Codecs/Rar.so

This kind of (relative) semblance, was what made me think of suggesting to possibly consider having less subfolders there... Maybe darealshinji can come up with more convenient / appropriate suggestions (hi djcj! had grabbed some packages from your ppas back in the past, so thank you as well). :-)

In any case, minor quibbles to maybe re-think of down the road... and as long they don't disrupt / complicate your own cross-platform developing workflow. It was meant more of a heads up in regards to the current deb while digging into new features. Pretty much everything and-the-kitchen-sink is added in the latest version, heh, so i'll just repeat once again that i really can't thank you enough in the first place... All the best

[tedsmith]

Thank you sir for the kind remarks and walkthrough. v3.3.0 was certainly a lot of work. I tried to roll in as many fixes and suggestions as I could, family life permitting!

I'm muddled at the moment about this particular issue because I thought we added the sub-dir prefix in the makefile as per this convo so I suspect we have missed a commit or a push somewhere because going through the commit history I cannot see this change commited.

We will get it resolved.

[tedsmith]

@darealshinji shall I address this one or would you prefer to do it? I didn't want to start if you're already got it in hand?

[darealshinji]

@tedsmith Go ahead.

[tedsmith]

@alicektx I've adjusted the Makefile last night and tested again on a new Linux Mint 19.3 VM, and all seems to be well. I tested it with an E01 too, and it worked. So I pushed the change to master. Tonight, if I get chance, I'll rebuild the Debian package, re-hash it, re-zip it and upload it. Perhaps you might be kind enough to try it out for me? You'll need to uninstall first (sudo dpkg -r quickhash) of course.

[tedsmith]

Re built, and re-uploaded. New Debian package available here . Thanks very much for the very helpful report.

[alicektx]

Yeap, deb works as intended out of the box now, thanks Ted!