Dear Maintainer,

dosfsck is very broken. Some of the brokenness is described here:

https://retrocomputing.stackexchange.com/a/32298/418

I have been working on a solution (that just so happens to also solve
#384976 and #771091), but it's going to be wildly controvesal,
and the result I expect is at least two solutions appear with different base
properties from completely different source trees.

However dosfsck is installed with fsck.fat being the actual binary and the
others as symbolic links to that. Which is no good at all for switching out
binaries. In any case, with the estimated number being three, dpkg-divert
won't work anymore; and /etc/alternatives is necessary.

Much has happened since I filed this bug, and much I have learned.

1) dosfstools is abandoned upstream. I have received email from the
prior maintainer
indicating that he is locked out of github apparently by intentional
action on github's
part; and furthermore he's quit maintaining it rather than try to
migrate to another hosting
provider only to have the same happen again.

2) FreeDOS's need is greater, so I have been laboring there; my own
attempt at solving
this problem for FreeDOS has reached alpha4, and it's currently
looking better than
the shipped dosfsck for use. Soon the time will come when I am ready
to publish the
release version.

3) I see in the mind's eye the following solutions to running my
solution for Linux's
benefit: run under dosbox or run under dosemu2. This will be wildly
controversial,
but right now dosfsck doesn't repair power loss damage very well,
which is the whole
point of having such a tool. I have considered the possibility of
transpiling my assembly
code; but I'm really hoping somebody else produces a high level
language solution;
thus leaving *yet another* version to choose from.

I suppose somebody could consider the existing dosfsck code and try to fix it,
but that somebody isn't me. I found a gut-replace to be in order, and
nobody wants
to maintain a debian patchset that's bigger than the original code.

Setting to release-critical

Why *this* bug?

1) This is the bug that reports abandoned upstream
2) fsck.fat and mkfs.fat are in the same package;
but only fsck.fat has important bugs that make it
unsuitable for purpose. The current status of
fsck.fat is if it reports issues, close it down and
switch to something else.
3) This bug is in my way for providing a stopgap fix;
if cleared, I could immediately provide a working
package (with a horrible dependency list) that does
this fsck.fat's job. I'm pretty much ready for extensive
testing at this point.