Any bug encountered on ReactOS, but not encountered on Windows is a bug in ReactOS, not the installer. They claim to be binary compatible to Windows, thus even if they provide a file system that isn't normally available on Windows (namely BtrFS) it should nevertheless just work without modifications needed by us.
I consider myself to be very much MITM here, and am- I assure you- extremely uncomfortable in the role.
This is hardly the first time that I have had cause to criticise btrfs, although in the past (elsewhere) it has mainly been related to incompatibilities between the Linux kernel and the filesystem driver: generally speaking, an insufficient negotiation of capabilities, and a failure to report a mismatch of capabilities as an error.
I haven't a clue how to find my report on Mantis, but I think I phrased it that the problem appeared to be that ReactOS's btrfs driver assumed that there was some maximum amount of data that could be committed per 30-seconds, but that the Lazarus installer exceeded this.
It should not be the installer's responsibility to fix this by inserting explicit flush or sync syscalls: the operating system (i.e. ReactOS) should Just Work.
At the same time, I feel that as the more specialised project it is FPC/Lazarus that should be on the defensive here, and that /if/ there was some way of keeping the host OS happy it would be to our advantage.
Updated: I'd incorrectly written bcachefs when I should have written btrfs.
MarkMLl