Back to HEN-3.0.3

[esc0rtd3w]

@DeViL303 sorry for the double post, but here are bins without the extra mutex output in logs. It's a bit easier to read

 

[bguerville]

I used a mutex deadlock implementation to solve the recursivity issue.

The rif and the photogui features currently make recursive calls, however I didn't touch that code, they already handle recursivity in their own way and I could not decide whether stuff like rap folders or photogui related files should be kept re-mappable or not, so I left everything as is, the mutex is there, if anyone wishes to reuse it and apply it to other recursive calls made in the hook.

The logs should probably be adjusted, stat OK/NG is an apt description but may not be the best way to log, also as is the mutex lock/unlock info floods the logs, it's better commented for the time being, I am thinking about adding several log levels details managed through a compilation flag, a bit of granularity should help users get logs that are "easier" to read while still keeping the option to get more detailed output if required.

@DeViL303
Please test the payload esc0 posted in situ, let me know if you detect any perf impact or other issues.

 

[DeViL303]

@esc0rtd3w @bguerville Thanks a mill guys, I will get on that now today. Got distracted with a rabbit hole about SDAT files there.

Really it would suit to me best to have it on Rebug or Evilnat, as HEN is still not 100% stable, when you reboot as much as I need to it freezes sometimes, and that just makes everything more difficult, and leads to more chance of corrupting my file system etc.

I know I have mentioned it before, but something to think about for the future would be logging URLs, that would be amazing, would really help with debugging online resources in different projects, with so many files in apps like Home its hard to know what URLs are being called or even where to look for URLs that might be called.

 

[DeViL303]

The logs should probably be adjusted, stat OK/NG is an apt description but may not be the best way to log, also as is the mutex lock/unlock info floods the logs, it's better commented for the time being, I am thinking about adding several log levels details managed through a compilation flag, a bit of granularity should help users get logs that are "easier" to read while still keeping the option to get more detailed output if required.

@DeViL303
Please test the payload esc0 posted in situ, let me know if you detect any perf impact or other issues.

Sorry about delay.

Seems to be no noticeable performance hit. Its way better alright, much more information. The extra lines do flood the logs a bit. Having certain stuff highlighted in different colors is great too, like if we could have green for found red for not found or something that would be one way to show more information without adding extra lines for each file. I know I can log to a txt file and search it after but its nice to have it in real time too.

BTW, on that subject, is there a command so I can see the socat log in real time but also log it to a txt file at the same time. Up to now I have only had commands to do one or the other.

socat -u udp-recv:18194 stdout

And

socat -u udp-recv:18194 stdout >>log.txt

 

[aldostools]

Sorry about delay.

Seems to be no noticeable performance hit. Its way better alright, much more information. The extra lines do flood the logs a bit. Having certain stuff highlighted in different colors is great too, like if we could have green for found red for not found or something that would be one way to show more information without adding extra lines for each file. I know I can log to a txt file and search it after but its nice to have it in real time too.

BTW, on that subject, is there a command so I can see the socat log in real time but also log it to a txt file at the same time. Up to now I have only had commands to do one or the other.

socat -u udp-recv:18194 stdout

And

socat -u udp-recv:18194 stdout >>log.txt

I use this command line to log in real time and capture the log to a text file.

socat -lu stdout udp-recv:18194,reuseaddr |tee stdout.txt

For colored messages it would be needed modify the payload to include ANSI codes.
https://www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html

 

[DeViL303]

This is actually great @esc0rtd3w @bguerville. Game changer.