I checked the actual patches in the repository. Th...
# aros
c
I checked the actual patches in the repository. The FAT-specific patches are 0006, 0008, and 0023. They are all addressing the same underlying class of problem: FAT is a little-endian on-disk filesystem, while AROS/m68k is big-endian. In English, I would describe them like this: •
0006-fat-write-cluster-and-size-little-endian.patch
— Fixes the write side of FAT directory entries. File sizes and first-cluster fields were being written in the host’s native byte order. This went unnoticed on little-endian AROS targets, but on m68k the values were byte-swapped on disk. This could corrupt the filesystem metadata; the patch specifically documents cases such as a 17-byte file appearing as
0x11000000
. It converts cluster numbers and file sizes to little-endian before writing them. •
0008-fat-convert-directory-dates-little-endian.patch
— Fixes FAT timestamps. FAT date/time fields are also little-endian, but AROS was reading and writing them as native `UWORD`s. On big-endian systems this produced invalid timestamps and made files written by AROS incompatible with other FAT implementations. The patch converts FAT dates/times when crossing the filesystem/on-disk boundary. •
0023-fat-read-the-first-cluster-fields-little-endian.patch
— Completes the work started by
0006
by fixing the remaining read-side first-cluster handling. Some code compared the raw little-endian directory-entry fields directly with native m68k values. As a result, directory traversal could fail beyond one directory level. In Bellatrix this had a particularly important consequence:
ParentDir()
could fail, causing
C:Copy
during
Startup-Sequence
to silently fail when copying
ENVARC:
into
ENV:
. The patch also fixes the same endian issue when renaming files and writing the FAT volume ID. So a concise explanation for upstream discussion would be: Patches 0006, 0008 and 0023 are FAT filesystem fixes. They correct endianness assumptions in AROS’s FAT handler. FAT stores its multi-byte metadata in little-endian format, while m68k is big-endian. The existing implementation relied in several places on host byte order, an error that remains invisible on little-endian targets but causes corrupted file metadata, invalid timestamps and broken directory traversal on m68k and other big-endian AROS targets. These are therefore not Emu68-specific fixes; they are generic FAT fixes for big-endian AROS architectures. That last point is particularly important: according to the patches themselves, these are upstream AROS FAT bugs exposed by Bellatrix/Emu68, not Bellatrix-specific workarounds. The patch descriptions explicitly identify m68k-amiga, ppc-native and ppc-morphos as sharing the affected code. Bellatrix FAT/AROS patches on GitHub⁠