[Oberon] Re(2): Compilation of A2.

[Michael Schierl]

Hello Peter,


Am 28.12.2025 um 20:45 schrieb peter at easthope.ca:

> # git show | head -n 1
> commit ec4ce23120a0e392b1d3be17ef77d23bafae435c
> 
> Same as you have.
> 
> Incidentally, I haven't seen a name for the number.
> Commit number?

Commit hash. But you are right, it is rarely needed to name it. When you 
have something that looks like a commit hash in the context of git, it 
usually is a commit hash. (Tree hash or blob hash would also look like 
that, but you usually explicitly say it is a tree or blob hash when it is.)

>> Something is different not in EasyOS but in your install.
> 
> Devuan and Easy both use the same A2 in a directory.  Only one A2.

In that case I'd double check mount options are same between Devuan and 
EasyOS (acl vs. noacl would be an obvious example that causes different 
behaviour) and double-check permissions. A file readable by user "peter" 
on Devuan does not have to be readable by user "peter" on EasyOS, as the 
user IDs can differ.

> My  sketchy thinking: Oberon.Files.Write puts one character at a time
> into a buffer in memory.  After Base64 decoding is complete,
> Files.Register copies the buffer to persistent storage. (What if the
> Linux code invoked by Files.Write differs between Devuan and Easy?)

Oberon.Files.Mod calls into Files.Mod which again calls into 
Unix.UnixFiles.Mod. And that filesystem implementation's "New0" 
procedure creates a new tempfile named ".tmp.<sequence>.<pid>" in work 
directory using "openat" syscall. The "Register" call will then rename 
that file to the final file name (and usually will leave it in work 
directory). In case rename fails (e.g. due to EXDEV if destination file 
is in a different filesystem) it will instead copy and unlink. In any 
case, after having done so, it will re-open the file with its 
now-current name.

On Devuan, you can verify this by running
"strace -f ./oberon run a2.txt" and checking the output. As far as I 
know, EasyOS does not come with strace, so you cannot do it there.

So, depending on cache behaviour of your Linux kernel, even before 
Files.Register, the file content may have been written to disk. It is 
just not usually visible since A2 cleans up its old temp files once they 
are no longer referenced, and ls -l (without -a) will not show them. And 
since there is no explicit "fsync" call, even after Files.Register it is 
not guaranteed that the file content has already hit your persistent 
storage (But it will eventually happen when the filesystem is synced or 
unmounted).


Regards,


Michael