[Toybox] mkfs.vfat / mkdosfs (was: Re: [PATCH] grep: add --line-buffered and fix regular buffering.)

[Rob Landley]

On 4/26/19 3:14 PM, Ivo van Poorten wrote:
> On Fri, 26 Apr 2019 14:54:38 -0500 Rob Landley <rob at landley.net> wrote:
>> the gzip second file bug and finish deflate and the new mkfs.vfat and
>> ...
> 
> Many years ago I started on mkdosfs, but RL got in the way.

I get in the way a lot. :)

> Meant to
> continue with it for years, but well, other projects, blabla

https://github.com/landley/toybox/commit/055cfcbe5b05

Grass houses and throwing stones...

https://www.youtube.com/watch?v=Ka2Eu6LxAKo
https://www.youtube.com/watch?v=RzDMCVdPwnE

I'm unlikely to complain about somebody _else_'s todo list runnething over.

> At the moment, it doesn't do much beyond some calculations and checks,
> but it contains a lot of notes at the beginning about corner cases,
> pitfalls et cetera. Might be helpful:
> 
> https://github.com/ivop/toybox/blob/master/toys/pending/mkdosfs.c

Cool, thanks.

I spent ~4 days on this over the holidays and half a .c file and notes, but the
problem is I can't go "I don't want to bother with fat12"... you have no choice.
It distinguishes fat12 from fat16 by size, and fat32 is this horrible thing
layered on top of it, and I have a lot of notes and several bookmarked web pages
but mostly I was looking at a hexdump of mkfs.vfat and going "huh".

Attached is where I left off, most of the output was a big "fat.txt" file and
directory of snippets I have to review and collate.

I think I know what to do now, but this is going to require the kind of testing
where I'm probably just going to dd files of each 512 byte size from the
smallest one that formats (um, 68 blocks I think it was?) through a terabyte or
so). It's all historical nonsense and none of it's systematic. I has a sad.

(I also, many moons ago, had to fix cross-linked files under DOS with a hex
editor on the partition, so "oh right, allocation bitmap with a linked list of
used entries..." And I remember old discussions about the long filename patent
and Linus pointing out his old code where he'd figured out how to do it as prior
art...)

I _also_ want to have a "genvfatfs" command produce output like an archiver
(qemu does something like this, or did at one point, producing a filesystem
image on the fly from a directory for its emulated system; read only and it
barfs if you modify files on the host behind its back, of course).

The reason I stopped with the mke2fs stuff is I worked out that I want to be
able to "gene2fs dir | gzip" which means it can't seek on the output (which the
existing gene2fs did and is a certain amount of effort _not_ to do) which means
it needs to read all the metadata up front which means I needed to write dirtree
first, and that took a while and I haven't cycled back to gene2fs since, kinda
wanted to do tar and zip first to see if there was more shareable
infrastructure; so far doesn't look like it. But "my version handles "cat tar.gz
| tar x" autodetection and debian's doesn't is the same sort of wanting to do
the obvious things the other ones didn't bother to. If you're gonna autodetect,
stdin should not gratuitously fail to autodetect... Grrr...

Oh, and mtools. Toybox should probably have some variant of mtools too, except
not "mcopy" and "mtype" dos format but "mls" and "mcat" which is in the pile
with "zgrep" and friends as "is there some way to wrap a command in a generic
way..." Numerous unresolved design questions there...

> Regards,
> Ivo

Thanks,

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkdosfs.c
Type: text/x-csrc
Size: 8369 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20190426/8d37bd3c/attachment-0002.c>