64x wrote: However, upon loading the engine again file goes back to original size (4MB).!

This happened to me in a buggy gui app that activated the "Clear persistent hash" button on every startup.

I kept investigating and it seems scidb might be buggy after all as it probably clears the PH/session files on each engine launch (same problem with Critter).
Sorry!

More precisely it looks like the standard Shredder format PH entries get overwritten by X-fen whereas the latter don't leave a trace altogether in subsequent analysis (even though the PH file seems to grow).
I've encountered this scenario in scidb application which seems to store/import c960 games ...

Hi,
Correct if I'm wrong but shouldn't both formats lead to the same stored position in the PH file? Right now if you analyse a 960 chess position given in X-fen there's nothing available if you go back to it in Shredder format.
With both castling rights available (and 2 rooks present) or 1&1 there ...

I don't think so - I remember compiling qdbm and kyoto though.
I'm attaching an strace of the symlink scenario.

Clearly, the issue must be related to the fact FAT is not a real unix fs and stockfish might be trying to do sth unix specific on the file or if you can't replicate the problem, maybe certain mount flags of that fs forbid it.

Thanks for the in-depth reply!
I have probably found an issue so let's move to the really important stuff.
On linux, upon engine startup if the PH file is a symlink to a file on a usb device (fat filesystem) the symlink gets replaced with the actual file. If the full path to the external filesystem ...

Yeah, but is it equivalent to PH off in a completely new position NPS-wise?

Is it possible with the currently available UCI options to get the following behaviour:
Stockfish uses the PH to read what has been learnt but doesn't write anything back. A sort of read-only/book approach.
Thx

Comedy gold!