Menu
▾
▴
#11 migrate to the latest libewf
I know that libewf is not stable. However, the latest version is libewf-experimental-20171104 and it were few API changes. While some changes are minor and renaming a function is enough, here is a major one:
https://github.com/libyal/libewf/commit/cae4c9b44e006c868e43bfe0bc49ad521afe2b7e#diff-183551695b6db84bc48acd291d97697d
it's about "libewf_handle_prepare_write_chunk"
Could you please migrate to the latest snapshot?
Thank you.
Do you have a special reason why you would like to use the newest libewf?
Since years already, Guymager runs with its own EWF functions which are enabled by default. In other words, libewf is no longer used, except if you do the neccessary change in the configuration file manually. I'm not sure if anybody ever did that...
BTW: The reason why I wrote my own EWF functions was that I had enough of adapting Guymager again and again to the many API changes of libewf. Isn't it ironic that you now ask me to do exactely this? ; )
Last edit: guy 2018-01-07
this is confusing. I simple compile guymager.pro and it finds a system libewf, creates makefile with "LIBS = $(SUBLIBS) -L/usr/lib64/qt4 -lz -ldl /usr/lib/libguytools.a /usr/lib/x86_64-linux-gnu/libewf.a"
So later the build fails due to API change.
I can see a call of local include "libewf.h" but there is no such local file.
Could you point out where I can find it?
P.S. You should also realease a proper source file (.tar.gz) not the .deb or .rpm.
In deed, using <> instead of "" for including libewf.h would be a bit nicer. I'll change it in the next release. But it doesn't make any difference as there's no local libewf.h. From the GNU documentation:
libewf.h is contained in package libewf-dev. However, in order to avoid all problems I encountered so far, I choose a libewf version where I know it works, build it myself and link it statically to Guymager.
Did you follow the instructions on guymager.sourceforger.net? If yes, please tell me what OS you're using and I'll to reproduce your problem.
The tar.gz files are available under subdirectory LatestSource in Guymager's download section on Sourceforge.
Last edit: guy 2018-01-08
Ok, so guymager does not "runs with its own EWF functions, and libewf is no longer used" as you mentioned initially. It basically needs an outdated libewf.
I'm a developer of Pentoo (Gentoo) Linux and I'm porting your tool.
Our goal is to use as less bundled/static libraries as possible so that the system would be "cleaner". You will probably agree that the current recommened method (to compile it locally and link statically) is not the best approach.
We do have few versions of libewf including the recommended "20140608" snapshot, however they can't co-exist, meaning you can't install 2014 and 2017 at the same time (at this moment at least). So we ported other tools to support the latest 20171104 already and guymager is the shortstopper for now.
I have started to port it as well and changes are minor and trivial. However, the last API "libewf_handle_prepare_write_chunk" function requires more then 1 line patch and I do not want to mainain it.
Those, this suggestion. You might want to create an experimental tag and try the latest libewf.
Well, If you only cite half of my words then the sense becomes a different one.
I thought you just would like to recompile Guymager for your own needs. Now that I know that you're working on Pentoo, I can understand your needs and philosophy. However, I do not like to restart the game of adding another series of #ifdefs to my code every time a new libewf is released.
My suggestion would be that I add an option to compile Guymager without libewf. If that helps you please tell me and I'll add such a switch.
well, that's not perfect but it will do for now. I fully understand the frastration with libewf since they change the API way to oftern and it is simply not repliable for production usage.
I just created a new Guymager test version where I (among other small things) included a flag for compiling without libewf. Contact me via develop at faert dot net if you would like to test it.
Last edit: guy 2018-01-24
Thank you for sharing the code, I have tested the test version and managed to compile.
As expected, it no longer supports EwfFormat.
On a side note, the current requirment to use libewf-20140608 seems strange.
That version might not support the latest EnCase or might have some bugs (just a speculation).
I'm sure you would need to migrate at some point, and I dont see any point in supporting an old one. It would allow to get rid of uncessary "#IF"
Just two clarifications for the other readers - in order not to mislead them:
When compiling Guymager without libewf it still is perfectly able to generate image files in EWF format. It does so by using its own EWF functions (which is the default configuration anyway). It even still has the EwfFormat configuration parameter. However, it'll only accept one setting, namely "AEWF".
There are only small, subtle differences in the EWF subformats that libewf is able to produce. EWF files generated by Guymager, no matter if using its own or the libewf functions for doing so, are readable by any forensic software.
Concerning libewf-20140608: I stayed with an that old libewf version because I was tired of the API changes. If you do not like this you now have the possibility to compile without libewf (maybe I even will make that the standard in future).
If you really need the newest libewf then please make it work with Guymager yourself and I'll happily take your code changes for integrating them into the next release.
ah, ok. Good to know. Thank you so much!