There has never been a 'real' udf.fsck tool on linux. For repair / mark clean a udf filesystem. The binary provided is merely a placeholder. So I'm filing this bug in the hopes that anyone interested will want to port the existing code / tool from Illuminos project (openSolaris codebase). Here is a counterpart bug on ubuntu, where you can find further useful information: https://bugs.launchpad.net/ubuntu/+source/udftools/+bug/384156 Just was talking on IRC today with ryao who believes it may be possible / achievable objective. Here's the relevant part of the IRC logs: [17:42] < dreamcat4> ryao: illumos has a 'udf fsck' tool, to error check a udf filesystem. but there is no such tool on linux. is that something which could be ported across from illumos --> linux? [17:44] < ryao> dreamcat4: It could. [17:44] < ryao> dreamcat4: You would likely want to use devpro-make to build it (not the openoffice dmake), but it should definitely be buildable. [17:45] < ryao> dreamcat4: It might also need some tweaks to build, although Illumos is very standards compliant, so it should not require much effort. [17:45] < dreamcat4> ryao: i had a look at the src code. but then found that the 'udf fsck' utility linked to and depended a lot on other more general shared lib. so i gave up on it. [17:48] < ryao> dreamcat4: It looks like it links to libadm, which does stuff with VTOC... there is code in ZoL for dealing with the compatibility, but it isn't really in a form that can be cleanly linked. [17:48] < dreamcat4> ryao: yes. precisely. [17:48] < dreamcat4> beyond my pay grade [17:49] < ryao> dreamcat4: DKIOCINFO is implemented in ZoL. DKIOCGVTOC is not. [17:50] < ryao> dreamcat4: It probably could be working with a weekend of effort by someone interested in porting this. [17:50] < datacat> DKIOCINFO, lord of Zol [17:50] < ryao> dreamcat4: See efi_ioctl() in ZoL's lib/libefi/rdwr_efi.c. [17:51] < dreamcat4> ryao: i asked on open ubuntu ticket (and gave them a link to the relevant part of the illumonos src code). nobody picked it up. [17:51] < ryao> dreamcat4: Try opening a ticket with Gentoo. Also, mention the ZoL code for DKIOCINFO. [17:51] < ryao> dreamcat4: It likely would get assigned to me. I might port it at some point. [17:51] < ryao> dreamcat4: You can manually assign it to me with @gentoo.org after my nick. [17:52] < ryao> dreamcat4: No promises though. I have a list of more than a dozen things to do. [17:52] < dreamcat4> ryao: (for reference) ubuntu ticket https://bugs.launchpad.net/ubuntu/+source/udftools/+bug/384156 [17:52] < ryao> dreamcat4: Include that reference in the Gentoo ticket. [17:52] < dreamcat4> ok. thanks ryao. i'll raise on gentoo
I am taking this bug, but I cannot promise to do the port quickly. If someone else is interested, they should feel free to do it. Just for the record, I am not that thrilled with becoming the maintainer for a udf.fsck tool, but I am willing to do it as my time allows to help out the community, should my time allow me to do the port. I do have two gripes though: 1. fsck = filesystem check. Having a filesystem check tool be anything other than real-only is perverse. The XFS guys had the right idea in making separate xfs_check and xfs_repair tools. 2. UDF is a legacy filesystem and if it were not for optical disks using UDF, people would not care about UDF very much. Consequently, we must maintain support for UDF indefinitely. I am not a fan of the optical disks because the level of quality in manufacturing them can lead to significant variations in life expectancy, they are typically write once and the rewritable versions tend to have compatibility issues.
prefix has no business here
Still a problem in 2023. I just had a BD-RE udf filesystem corrupted by forgetting to mount it ro and then forgetting to run umount before unplugging the drive. Left it in a state where I can see the data with hexedit but it won't properly detect the UDF on linux or windows. Thankfully this was an archive I made other copies of, but it lead me to discover this situation. A further discussion here of situation here: https://github.com/gmerlino/format-udf/wiki/fsck-tools-for-UDF It does not include the newest developments. NetBSD also has their own fsck_udf ( now which was funded by a bounty and completed in past few year. This seems most promising and someone claims it works on Slackware: https://github.com/Randrianasulu/fsck_udf I'll try it and report back. If it works I would be willing to write an ebuild and proxy maintain it.
Yeah netbsd version is going to take some additional porting work. It won't read directly from a device (reports device is not a raw device) and a newly created udffs image spits these errors: /home/joecool/fsck_udf/fsck_udf test.udf ** Checking UDF file system on test.udf ** Phase 1 - discovering format from disc Filesystem sectorsize is 512 bytes. Volume set `64cfef94fef853b8LinuxUDF` Primary volume `LinuxUDF` Logical volume `LinuxUDF` Bad descriptor sum in vds, ignoring Bad descriptor CRC in vds, ignoring Unknown VDS type 27872 found, ignored Minimum read version v2.01 Minimum write version v2.01 Maximum write version v2.01 Last logical volume integrity state is CLOSED. Format flags ���]�U Couldn't read in file set descriptor implementation limit: can't fix this Failure reading volume descriptors, disc might be toast I'll keep on this and tip in the other distros.
