Heterogeneous eosd/eosxd clients / eosxd cache management

Hello,

A general question about the use of both eosd and eosxd clients to access the same files. Are there some good practices, things to know, avoid, etc…The idea is of course to gradually migrate all the eosd clients into eosxd, but in the meantime we have a mixed set of clients.

Is it for instance better to prefer the use eosxd client to modify files ?

We observed once the case of a file that was modified by a eosd client, but not updated on a eosxd clients, even days after the modification (i.e. the list shows old timestamp and size, and read shows the old content), until the eosxd client is restarted. The file is much probably frozen in the eosxd client cache. We could observe for instance three different version of the same file at the same time, on 3 different eosxd mount.
This seems to happen only under some conditions that we don’t really understand, maybe someone can help on that. Maybe this happens if some process accessing has a “lock” on that file, or keeps it open ? But then, also other processes accessing the file on the same mount see the old version of the file, which is not expected.
We understand that the fuse clients are not included in the mechanism to notify immediately the eosxd client of changes, but we would have expected to see the changes after a while (some minutes).

More generally, is there a way to manipulate (like clear) the eosxd cache without restarting the client ? Or some parameter that would limit the time files are kept in the cache, to force fetch them again from the server ?

We confirm that in some situations (a configuration file opened and read at the launching of an application), accessing the file from the same fusex mount by any application do not see any further change made in this file. The way we found to ensure that the file is updated is to remove it before rewrting it (i.e. create a new file ID). Is this a normal behavior, or could we find some way to observe the changes made within the same file ?