logic problem with syscalls which should fail

[rurban]

maybe always returns success for intercepted syscalls, if they should fail, e.g. a not-existing file, thus changing the logic of the program.
maybe should check per syscall if the syscall might succeed.

[nwoolls]

What if the underlying program first moved a file from location A to B, then from B to C. With this suggestion how would maybe know to return success for those calls, but fail for other file system calls where the file doesn't exist?

[rurban]

via a primitive statemachine (a dictionary) for example.

[nwoolls]

I'm sure it's solvable - it just seems the underlying mechanism used doesn't take this into account and the implementation would grow complex in order to solve this use case. Another missed use case is if the underlying program or script needs to read any of the modifications that were made.

This seems more like a proof of concept that will been limited in nature. The question becomes how much code is added to try to fill the gaps left by the original choice of syscall no-ops.

[rurban]

I would appreciate to add minimal hooks for possible false return values. I don't envision complex code to solve this, just a few lines. checking stat and keeping state in a dict is enough for some syscalls.

[nadrimajstor]

For what it's worth, maybe a layered file system could help e.g. OverlayFS (current state is mounted ro, changes are layered atop, tooling just records the changes)