oxmc
f6176009b1
Stages TWRP's GUI engine and standalone tooling as PawletOS-owned modules instead of a bootable/recovery fork, per the plugin-architecture finding in NOTES-ota-recovery-ab.md: stock recovery_main.cpp already dlopen()s librecovery_ui_ext.so and dlsym()s make_device() from it at runtime, so the UI layer doesn't require touching stock bootable/recovery at all. Confirmed via source grep that recovery.cpp/install.cpp have zero references into the partition manager/backup engine/GUI code and vice versa. recovery_ui/: TWRP's gui/, minuitwrp/, libpixelflinger/ (copied verbatim, GPL-3.0), plus a new device/ providing PawletTwrpUI (a ScreenRecoveryUI subclass) and make_device() — written from scratch against stock's RecoveryUI/ScreenRecoveryUI virtual-method contract, since TWRP's own fork never ships a make_device() (every real TWRP device provides its own, and no reference device tree was available to copy from). Top-level Android.bp defines librecovery_ui_pawlet_twrp, the module TARGET_RECOVERY_UI_LIB should point at. gui/Android.bp and minuitwrp/Android.bp had their include_dirs rewritten for the new paths. recovery_toolkit/: partition manager, backup engine (tar/digest/adbbu/apex), filesystem/format support (exfat/dosfstools/gpt/fuse/mtp/crypto), scripting (openrecoveryscript/orscmd/twrpinstall), shared helpers. Source only, no Android.bp yet for any of it. Known gap blocking recovery_ui from actually linking: gui/'s libguitwrp depends on libaosprecovery, built from recovery_toolkit/helpers/twrp.cpp via a Go Soong plugin (libaosprecovery_defaults.go) not yet ported. Neither repo has been build-tested — no local AOSP build environment available in this workspace. See each directory's README.md for a precise done/not-done breakdown.
61 lines
2.3 KiB
Plaintext
61 lines
2.3 KiB
Plaintext
dosfsck, version 1
|
|
==================
|
|
|
|
WARNING: This is ALPHA test software. Use at your own risk.
|
|
|
|
dosfsck is the Linux equivalent of PC/MS-DOS' CHKDSK. It checks the
|
|
consistency of PC/MS-DOS filesystems and optionally tries to repair
|
|
them. The tests dosfsck performs are described in the man page.
|
|
|
|
dosfsck needs header files from dosfs.9 (or later) to compile.
|
|
|
|
Before using dosfsck to repair a filesystem that contains data of any
|
|
value, you should verify that dosfsck is able to correct all reported
|
|
errors. (Except fatal errors and those reported as unfixable, of
|
|
course.) In order to do this, run it with the -V option, e.g.
|
|
|
|
dosfsck -V /dev/sda1 (automatic check)
|
|
or dosfsck -V -r /dev/sda1 (interactive check and repair)
|
|
|
|
dosfsck will perform two passes: in the first pass, inconsistencies are
|
|
detected and a list of changes to correct the problems is generated. In
|
|
the second pass, those changes are applied whenever dosfsck reads data
|
|
from disk. Hence no fixable errors should be reported in the second
|
|
pass if the first pass was successful.
|
|
|
|
Please notify the author if fixable errors are reported in the second
|
|
pass.
|
|
|
|
After verifying that dosfsck appears to be able to perform the desired
|
|
operations, either confirm that you want the changes to be performed
|
|
(if dosfsck was started with -r) or re-run dosfsck with the -a option
|
|
(if it was started without -r).
|
|
|
|
Please send bug reports, comments, flames, etc. to
|
|
almesber@nessie.cs.id.ethz.ch or almesber@bernina.ethz.ch
|
|
|
|
- Werner
|
|
|
|
FAT32 and LFN support
|
|
=====================
|
|
|
|
I've finally implemented some of the new features of MS-DOS
|
|
filesystems: FAT32 and long filenames.
|
|
|
|
FAT32 is automatically detected and of course the different FAT
|
|
structure is handled. (Internally many changes were needed, so 32 bit
|
|
variables for all cluster numbers and 64 bit vars for offsets inside
|
|
the filesystem.) New checks for FAT32 are most notably on the backup
|
|
boot sector and the new info sector. Also the possibility that the
|
|
root directory resides in a cluster chain (instead of in a static
|
|
area) on FAT32 is handled.
|
|
|
|
dosfscheck also knows about VFAT long filenames now. It parses those
|
|
names and uses them in listings etc. when available. There are also
|
|
some checks on the (cruel) structure of how LFNs are stored and some
|
|
attempts to fix problems.
|
|
|
|
- Roman <roman@hodek.net>
|
|
|
|
BTW, version 2 isn't ALPHA anymore :-)
|