Why extract from the log? You already have the file when you post it to the log... do the replacement real time rather than try to extract after the fact. So, as soon as you find the difference in your test, replace the reference file with the file you are about to write to the log. No need to do an extract.
The files are created on a host machine, I have the log files on the master, several tests projects are run on the host machine and every time it's wiped clean, I have potentially 100's of files to change and doing a procedure that updates all the files is way more effective
Then, alternatively, rather than extracting them from the log, in your script code, save the file to a centralized location.
I'm not saying it's not possible to extract the files from the log (I've not had need to) but the code for doing so is probably going to be a bit complex to be able to read the native log format, find the reference to the file, extract and decode the bit-stream, etc. So, rather than overcomplicating things, pick a shared directory location on some centralized file server, write the files to that, and then use that location as your source for processing and updating the files.
Thanks for the answer, that was plan b, I would have liked to keep the file differences in the logs to have an history of the modifications instead of having to manage different paths where to store the files in the script, it doesen't look like that the files are accessible via the log object I'll probably parse the xml logs
