Status? about node-mkfat HOT 38 OPEN

Huh, I forgot to update the readme. LFN has been implemented.

I think I left things in a pretty good state. That's the kind of use I wrote the code for in the first place. I think I came to the conclusion at the end that I would still have to run syslinux from the command line, but if you include the correct ldlinux.sys and ldlinux.c32, then syslinux just modifies a few things in place. Alternatively I did make a method (.addSpace()) that can reserve a little extra space for those files.

Sorry that the state of the documentation and testing is so poor, but my expectation is that you should find the code to be usable. Let me know how things go.

from node-mkfat.

I think I just found two bugs reading through the code. The first I'm not quite sure what to make of:

debug(`Pre allocated space by writing a 0 at ${lastByte}`)

which doesn't actually allocate the space on a filesystem that allows sparse files. I wonder what I was thinking when I wrote that. I think that was mostly to make sure the file comes out exactly the right size, in which case it's mostly just a matter of saying the wrong thing...

The second is something I became aware of more recently.

Note that it is unsafe to use fs.write multiple times on the same file without waiting for the callback

This was news to me last week, and I just noticed this code assumes that to be safe. The FS API is a wilting leaf on the blossoming flower that is NodeJS. Ripped straight out of C, not only is it unsightly and out of place, it manages to be worse than using C directly. It's interesting that this never bit me—it's always just worked. Hopefully this doesn't bite you before I get around to fixing it.

from node-mkfat.

I think I came to the conclusion at the end that I would still have to run syslinux from the command line, but if you include the correct ldlinux.sys and ldlinux.c32, then syslinux just modifies a few things in place.

So far with genfatfs didn't need to use syslinux, just copy the needed files... EFI is other story, seems almost impossible to make it work, but maybe something could be done...

Note that it is unsafe to use fs.write multiple times on the same file without waiting for the callback

I got on this pitfall too. Easiest solution here is to use writeSync(), but it's better to rewrite the code to make it async (if possible) and the best one is to use createFileWriter(), that creates a writable stream. Since you need to "go back" to write some data on the FAT table then writeSync() seems to be the only solution, at least for the final tune-ups after writting the data.

How much could it cost to add an API similar to tar-stream pack() method? This would make it fairly easy to use and add files. It doesn't need to written on file, with the smallest cluster size filesystem would not be greater than 512MB, so it could be hold in memory while working with it...

from node-mkfat.

My assumptions made me totally miss where you said '/boot' and what you probably meant by that. You're not creating fs images that include boot code - that goes in the actual MBR. Hence syslinux not being needed. I had started hunting through genfatfs code to see what sort of magic was going on. Long story short, feel free to ignore my comment about syslinux, it's not relevant.

Also, I pushed an update to serialize writing.

from node-mkfat.

As to the API for adding files, I've been giving thought to some related ideas. It's what made me aware of the serialization issue. The code I provided here was the simplest thing I could think to provide since what I really wanted still wasn't clear at the time, and looked to be a large project in its own right (basically my current project). If I can find an answer to the problem I'm tackling right now then I'll probably want to integrate it here as well, and I'll be sure to give some consideration to tar-stream's method. I'm going to hold off on developing this feature here until my other plans have resolved a bit. If you care to pursue the tar-stream direction I'd be amenable to a pull request.

from node-mkfat.

My assumptions made me totally miss where you said '/boot' and what you probably meant by that. You're not creating fs images that include boot code - that goes in the actual MBR. Hence syslinux not being needed.

Yeah, that totally makes more sense :-D Yes, I'm doing partition images, not disk images, so no need to MBR :-) When doing disk images you need Syslinux to have a bootable MBR, I'm already doing so implicitly on genisofs with syslinux.bin.

I had started hunting through genfatfs code to see what sort of magic was going on.

I think it will be useful to you, code is really clear, and the one of genextfs is really clear too :-)

I pushed an update to serialize writing.

Great! I'll take a look :-D

As to the API for adding files, I've been giving thought to some related ideas. It's what made me aware of the serialization issue. The code I provided here was the simplest thing I could think to provide since what I really wanted still wasn't clear at the time, and looked to be a large project in its own right (basically my current project). If I can find an answer to the problem I'm tackling right now then I'll probably want to integrate it here as well, and I'll be sure to give some consideration to tar-stream's method. I'm going to hold off on developing this feature here until my other plans have resolved a bit. If you care to pursue the tar-stream direction I'd be amenable to a pull request.

Could you be able to explain what problem do you have? Maybe I could help you...

from node-mkfat.

I'm extremely unsatisfied with NodeJS's FS API; there are various different file related tasks that I need to accomplish, and I feel that require('fs') doesn't handle any of them very well. Conversely, streams work very well, but aren't always the right tool (like here). I'm trying to nail down exactly what my needs are and figure out how to address them. My ideas are starting to come together, but it's not entirely clear yet. When I get enough figured out I'll put something up on github, and let you know.

from node-mkfat.

You can upload it to a branch and let me review before push to master... Also Promises I don't think could be the best tool here, I had several problems last time I modified nos-init...

from node-mkfat.

I must apologize for my atrocious code quality there. I think there would have been even worse issues without Promises. A lot of my code has been very much a prototype. It's hard to justify the time to clean the code when I'm not sure if it's going to prove useful long term.

To be honest, I'm a little uncomfortable with some parts of node-mkfat as well. In particular, there are several properties I'm setting on the FAT class as it runs through various methods. This means that the methods which use these properties must be run in a particular order. It was the first thing I could think of at the time, and I didn't want to get too caught up in the design before I got the code working.

Since the file API is somewhat weak (as indicated by your request for the .pack() API, and my own thoughts on the matter) and I'm starting to think that cleaning it up will lead to other improvements, I think that's worth tackling first. Reviewing tar-stream's approach to files, etc. has been on my list of things to do for a few days now, and I finally got to it today (in part due to your request). As I think more about it, I'm starting to think it will provide an excellent starting point. Since .entry() from .pack() takes stat objects upfront it means that some of the async code becomes unnecessary. In general I'm starting to see files as being a pairing of stat objects with read and write methods. It seems kinda obvious when I say it like that. I suppose it's the opening and closing of files and the necessity of file descriptors, especially integer file descriptors that really have been bothering me. .entry() actually looks like a really good API from node-mkfat's perspective, but didn't really strike me as a good approach from a usability perspective when I was writing the code. It didn't suit my simple needs, nor the needs of a prototype.

Sorry for the long ramble there, but it has helped me think some of this through. Long story short, I think I will take the .entry() approach, and I think that will be a win both for the code quality of this project, as well as being a decent match for my longer term goals.

from node-mkfat.

In general I'm starting to see files as being a pairing of stat objects with read and write methods.

That's just how vinyl-fs (part of gulp) and fstream (part of npm) works, and it totally makes sense they do it that way... I'm not sure what one is using tar-fs is any, but if not surely it uses a similar approach.

I suppose it's the opening and closing of files and the necessity of file descriptors, especially integer file descriptors that really have been bothering me.

Are you talking about reading and writting the files? By using the stream API this greatly simplifies, it's very optimal for that kind of tasks...

I think I will take the .entry() approach, and I think that will be a win both for the code quality of this project, as well as being a decent match for my longer term goals.

What are you long term goals?

from node-mkfat.

Hmm.. Thanks for those links. vinyl-fs in particular looks very similar to what I have in mind at the moment, at least to start with. Longer term, my objective has to do with the kinds of things I was trying to do in nos-init, and to some extent also node-mkfat. Both of these projects had parts that felt like they should be done in bash. I refuse to accept that NodeJS is incapable of handling those parts elegantly, and I don't like how you can't encapsulate files with bash; ultimately they end up strewn about the filesystem. I figure that Node is the better language, and I'm better off figuring out how to express these file manipulations in Node. The challenge that I've been focusing on has been the lack of file size information and, to a lesser extent, lack of random access afforded by streams. vinyl-fs and fstream both appear to focus on how paths are dealt with, which is something I haven't given a lot of thought to. Definitely food for thought. That said, vinyl-fs doesn't handle file size or random access (except with buffers), and fstream doesn't really handle what I'd term anonymous files—file-like objects that aren't on disk.

Ultimately I'd like to bring the joy of bash scripts to node. That may be a bit too big of a goal, and I'd settle for making things like nos-init less painful. I may already be better equipped for that but for the moment I'd like to see my ideas through a bit further.

from node-mkfat.

You can have random access with streams because by definition they are sequential, but you can be able to store them in a file or buffer and have random access there. That's the way I would do it, write dummy metadata strucutures on a filesystem file, concat the files content, and when finished go back and update the filesystem metadata, that's how zip file format works.

from node-mkfat.

And how to accomplish that nicely is sort of what I'm looking at.

Anyhow, right now I'm looking at tar-stream. I'm not really liking how the path and name are combined on the stat objects it uses. I think it would be easier if name was just the name, and there was a separate path property. Would this be a problem?

from node-mkfat.

This is specifically with regards to node-mkfat. If I change the FAT class to have an .entry() method that takes stat objects, as tar-stream's pack system does. Does it cause problems if I expect the names and paths to be separate; are there good reasons to leave the path as part of the name on the stat object?

from node-mkfat.

I'm not really liking how the path and name are combined on the stat objects it uses. I think it would be easier if name was just the name, and there was a separate path property. Would this be a problem?

Well, that usually how filesystems works on UNIX... I would not think too much about it, and also if you need so you can always split the path...

Does it cause problems if I expect the names and paths to be separate; are there good reasons to leave the path as part of the name on the stat object?

Yes, to be compatible with how all modules expect to find it. The path is relative to the root of the filesystem, and as I told you, you can always split it...

from node-mkfat.

Thank you, your perspective here is helpful. I am intending to follow convention here, it's just not always clear to me what's important and what's not.

from node-mkfat.

Events, callbacks and ducktyping are important :-)

from node-mkfat.

I've got a start on the .entry() stuff. #2

from node-mkfat.

I have been thinking about this issue and think there's a solution: you can be able to .open() the dest file and use its file descriptor when calling to .createWriteStream(), so this way you could be able to both stream the files content and update the metadata, although I think this would be overcomplicated. A better approach would be to just use .write() to write the content as it's being done at this moment, and use .seek() and .tell() to change the place where data is being written to upload the metadata and comeback to the end of the dest file to add new files. This approach would also allow in a second development iteration to check the files size and change the chunks size on the fly if they are needed, changuing the ones of the previous files. How do you see it?

from node-mkfat.

I'm a little unsure what you're getting at. In terms of the metadata, taking the files' stat information upfront using the .entry() pattern means that I have all the metadata right away. It turns out that the only reason that I still need an fd for output is the implicit zeroes between writes. I've already started to think about turning the FAT into a Readable stream. Just add entries, and then pipe it out.

from node-mkfat.

That said, these changes are already taking longer than the initial full prototype. In other words, the key advantage of the FDs was how fast I could write the code.

from node-mkfat.

I'm a little unsure what you're getting at.

I'm talking about how to create a Readable stream, or at least how to create the FAT filesystem in an incremental way without needing to define a filesystem size from start.

In terms of the metadata, taking the files' stat information upfront using the .entry() pattern means that I have all the metadata right away.

This requires to have all the files already available, it's not possible to create it using a stream as tar-stream does. Just creates the data and fetch the metadata for each file object you get when calling to .entry(), not in advance. You don't need file descriptors at all, at least for the incoming files.

It turns out that the only reason that I still need an fd for output is the implicit zeroes between writes.

No, you can write instead zero-filled buffers for padding purposses.

Just add entries, and then pipe it out.

Yes, that's the correct way to do it.

That said, these changes are already taking longer than the initial full prototype. In other words, the key advantage of the FDs was how fast I could write the code.

Well, it could be if you are used to them, but in Node.js the way to go is to use streams and events and async behaviour, not file descriptors.

from node-mkfat.

No, you can write instead zero-filled buffers for padding purposses.

That's what I'm getting at with the Readable stream.

Well, it could be if you are used to them, but in Node.js the way to go is to use streams and events and async behaviour, not file descriptors.

Streams, events, and async are why I love Node. The problem is what lends itself to fds, at least without rethinking file representation, which I'd not encountered much. The idea of saying "here's a stream, and here's how long it will be" struck me as unexpected. I've gotten over it.

And back to the big one:

I'm talking about how to create a Readable stream, or at least how to create the FAT filesystem in an incremental way without needing to define a filesystem size from start.

That's a different project entirely. You can define a filesystem without needing to specify a size (this project), or you can define a filesystem incrementally (use natevw/fatfs for that). Since the size of the FAT is proportional to the the size of the FS, it has to be increased in size with every addition to the filesystem. Since the FAT is at the beginning of the image it means moving any files that it would overwrite, and worse, since it's not sized in clusters you would have to realign all the files to new cluster boundaries. And if that's not bad enough, occasionally an addition will force a change in cluster size, again meaning that all files and directories need to be realigned to the new cluster size. What this means practically is that either you know all your files ahead of time, or you preallocate space. If you really want to both avoid predefining the size and build the fs incrementally, then your best bet is to build on top of this project, and simply rewrite the whole filesystem after every change, since you wouldn't save many writes anyway even with much more complicated code.

from node-mkfat.

The change of the cluster size would be left for another module build on top of this one, but I think the increase of the FAT would be feasable up to some extend, since you need anyway to fill the FAT sectors, so you have some margin there... Also you could add some parameters to define what number of clusters do you want to allocate and what size of cluster and give an error when they need to be exceed. Having by default the minimal values that gives us up to 16MB, later we could add a mode where the FAT table would increase automatically, for our use case would be more than enought due to the size of the filesystems we are willing to create.

from node-mkfat.

Well, allocating extra space is something I've already got, and the minimum FAT 16 size looks like about 8MiB. I suppose it would be feasible to expand into the existing preallocated space, and re-writing directory entries as needed, so long as they don't overflow. I'm still not keen on writing it. It won't be general purpose, prone to failure when the parameters are exceeded. Still, some of what's needed is already there. I'm already attaching the cluster number to the entries I'm storing. The makeDirBuffer method should be trivial to rerun. The only problem is re-writing the fat. Can't do that with a Readable stream as output. Do I stick with an FD? I still want to switch to the Readable stream. I'd suggest just adding more files and streaming the image out again from the beginning... Hmm.. I can reset the internals, but I can't reset the input streams. Technically I could write a broken FAT without any last cluster markers; the filesize marked in the directories should be sufficient to indicate where to stop reading. With append only and no fragmented files I don't think that will cause any problems. The only problem is that you still can't go back and add an entry to any directory that has already been written. There is no having and eating of cake.

from node-mkfat.

Well, allocating extra space is something I've already got

I'm not talking about allocating extra space, but instead to create an
empty FAT table (no data area), append to it the files sectors, and upgrade
the FAT table and the directory entries the way the files are being added.
Later, maybe a .finalize() method or listening to the piped .end event
would add the required extra space and update the FAT table as it's being
done with the regular files, if so.

and the minimum FAT 16 size looks like about 8MiB.

So far I have seen 16MB, but if it's possible to have a smaller one with a
smaller FAT table, cool then :-)

I suppose it would be feasible to expand into the existing preallocated
space, and re-writing directory entries as needed, so long as they don't
overflow.

Yeah, since it's not possible to have a Readable stream API, that's was
just the way I would do it.

The only problem is re-writing the fat. Can't do that with a Readable
stream as output. Do I stick with an FD?

For the destination file yes, there's no other reasonable option.

I still want to switch to the Readable stream.

Well, if you want it so much, you could do the changes on a temporal file
and later stream it, but it's no sense since you are already writting it,
so it's better to use it directly. Other option would be to create the
filesystem in RAM and later stream it, but it would waste a lot of memory
for big filesystems...

I'd suggest just adding more files and streaming the image out again from
the beginning... Hmm.. I can reset the internals, but I can't reset the
input streams.

Forget about that, this will not work and confuse everybody.

Technically I could write a broken FAT without any last cluster markers;
the filesize marked in the directories should be sufficient to indicate
where to stop reading. With append only and no fragmented files I don't
think that will cause any problems.

It could work so long you fix the FAT table when you finish writting the
files on the filesystem.

The only problem is that you still can't go back and add an entry to any
directory that has already been written. There is no having and eating of
cake.

That's why I tell you about updating them on the fly, since you already has
references for them.

from node-mkfat.

Alright, I just finished cleaning up the bugs I introduced in changing the API. The output now matches the original output exactly.

from node-mkfat.

I've just review the code and it's more cleaner :-) Some things I have seen should be changed / have doubts:

• Use standard two spaces instead of tabs :-P
• ES6 class is cool, but it's not possible to see what's the public API, add an underscore at front of private methods
• Add JsDoc for each of the methods
• Are you storing the Stream objects on the .entry() method? I think it will not work with things like tar-fs or cpio-fs where only one Stream is active each time... This is easier since you have all the stat info, but would try to generate the filesystem on the fly
• Accept stat mode and other metadata and flags in the UNIX format (.mode entry) if possible

from node-mkfat.

Oh, and don't ignore links and symlinks, it's better to show an error or a warking or add an option to fake hardlinks or copy the data instead...

from node-mkfat.

Ok, I've read a bit more about the format of the FAT table and seems now I understand a bit more how it works. Seems the FAT table define each cluster with 16 bits, that's the limite of 2^16 clusters per filesystem, but the actual number of clusters available is defined in the Boot Sector Block of the FAT16 filesystem and it's dependent of the final number of sectors that will have the filesystem, that's the problem we have. FAT table fill the full sectors it's using itself, having 256 clusters for each sector it's using, that's why on the floppy disks it's using 8 sectors to hold the 4096 clusters that can be stored on the floppy by using 1 sector per cluster (512 bytes). This gives us the problem that us that we could have a filesystem as small as 128KB by using 1 sector for each cluster and just 1 sector for the FAT table itself (256 entries), but when going beyond this limit we would need to start moving data sectors to give some space to the sectors that will be needed by the FAT itself up to the maximum of 2^16 entries (512 sectors, 256KB just for the FAT table!!!), or increase the number of sectors for each cluster, that would make sense if we would know the average size of the files we are going to store, The kernel and the initram are fairly big and we are not going to store too much files, so probably it would makes sense too...

Anyway, it's not possible to have a write stream API here :-) If we want to create it incrementally make it would be possible to hold the data in memory or in temporal files in the hard disk and when it finished compose it in the final structure, mostly as you are currently doing it, how do you see it?

from node-mkfat.

This gives us the problem that us that we could have a filesystem as small as 128KB by using 1 sector for each cluster and just 1 sector for the FAT table itself (256 entries).

Bear in mind that anything with less than 4085 clusters must conform to FAT12 rather than FAT16. While it's not overly complicated to support FAT12 it is extra work. The main difference is that FAT entries are 12 bit instead of 16 bit. Feel free to submit a pull request if you care for the smaller images. I don't particularly care for the bit marshaling required.

Oh, and don't ignore links and symlinks, it's better to show an error or a warking or add an option to fake hardlinks or copy the data instead...

I'm actually generating hardlinks already. FAT claims to not support hardlinks because otherwise you'd have to iterate over all entries in the filesystem to know whether a given cluster was safe to delete, but since I'm expecting the images to be read only there's no reason not to support them. The symlinks issue does highlight a disadvantage of the .entry() API—it allows input that doesn't conform with internal expectations. You're right these should throw an error.

Are you storing the Stream objects on the .entry() method? I think it will not work with things like tar-fs or cpio-fs where only one Stream is active each time... This is easier since you have all the stat info, but would try to generate the filesystem on the fly

Definitely storing. There's really no alternatives here. I may be best off backing out the merge. This project is definitely not the place to handle caching of large file objects. Either the streams can be held onto until needed, or we use FDs as per my original design. Or we wait for a better alternative.

Use standard two spaces instead of tabs :-P

'Standard' is for the inferior who cannot recognize the gloriousness of tabs. I will not accept pull requests without properly tabbed source. For further discussion see here.

ES6 class is cool, but it's not possible to see what's the public API, add an underscore at front of private methods

Good plan.

Anyway, it's not possible to have a write stream API here :-) If we want to create it incrementally make it would be possible to hold the data in memory or in temporal files in the hard disk and when it finished compose it in the final structure, mostly as you are currently doing it, how do you see it?

Yeah, that's kind of been the idea all along. This code generates the image. Making it take care of all the marshaling is definitely out of scope and incompatible with the whole idea here. The code is designed around the idea of taking advantage of preexisting knowledge of the complete final set of files to build a minimal image. While there are some possibilities for a sort of middleground between this code and the traditional approach where you make an empty image of a given size and then fill it, it involves a lot of additional code.

I need to put this project on the back burner right now. I've gotten some valuable insights from this week's efforts and discussions, but I can't put more time into this right now. I'd be happy to look at any pull requests though.

from node-mkfat.

Accept stat mode and other metadata and flags in the UNIX format (.mode entry) if possible

Not possible. FAT has no concept of users or groups, having only a set of global flags: RO, Hidden, Sys, 'Volume Label', Directory, and Archive. Of which only RO maps even partially to mode.

from node-mkfat.

Bear in mind that anything with less than 4085 clusters must conform to FAT12 rather than FAT16. While it's not overly complicated to support FAT12 it is extra work. The main difference is that FAT entries are 12 bit instead of 16 bit. Feel free to submit a pull request if you care for the smaller images. I don't particularly care for the bit marshaling required.

I was just doing some maths, the 4085 clusters is just the recomendation done by Microsoft, but as I show you the filesystems allow other etensions :-) Obviously, for such small filesystems is way better to use FAT12 or also the original and almost unknown (and unsupported) FAT8...

By the way, according to my calcs, 4085 clusters is the quantity needed by a 2MB filesystem using 1 sector per cluster (16 sectors for the FAT).

I'm actually generating hardlinks already. FAT claims to not support hardlinks because otherwise you'd have to iterate over all entries in the filesystem to know whether a given cluster was safe to delete, but since I'm expecting the images to be read only there's no reason not to support them.

I think this should be an opt-in, they doesn't hurt on read-only filesystems but would do for ones that are going to be written later...

The symlinks issue does highlight a disadvantage of the .entry() API—it allows input that doesn't conform with internal expectations. You're right these should throw an error.

Same for this, they could be converted to hardlinks too :-)

Or we wait for a better alternative.

I think the files sectors could start to be concatenated and when everything is downloaded just create the FAT table and put it in front of the concatenated files.

'Standard' is for the inferior who cannot recognize the gloriousness of tabs. I will not accept pull requests without properly tabbed source. For further discussion see here.

Lol! :-P Well, yeah, I used to use tabs because it's the logical thing to do to tab code, but I started to use 4 spaces with Python, later 2 with Javascript, and now I find two tabs to be the easy option, specially if code will be published on the web :-) Anyway it's your project, so tabs is ok for me :-)

ES6 class is cool, but it's not possible to see what's the public API, add an underscore at front of private methods
Good plan.

Ok, let's review that.

The code is designed around the idea of taking advantage of preexisting knowledge of the complete final set of files to build a minimal image.

Yeah, and seems the FAT format force to do it this way... :-/ A progresive way could be done, but this would involve more work. Maybe concatenating the sectors in a temporal file in the hard disk while the FAT table is being modified in RAM, and when finished stream the FAT and the temporal file one after the other... This way there would not need to write back on the disk, just append sectors :-)

I need to put this project on the back burner right now. I've gotten some valuable insights from this week's efforts and discussions, but I can't put more time into this right now. I'd be happy to look at any pull requests though.

Fair enough, I'm happy you foung inspiring our conversation regarding this :-) I'll try to look if I have time to see how to improve it :-)

Of which only RO maps even partially to mode.

Yes, that's just the only one I was talking about, other ones would need to be set manually.

from node-mkfat.

I was just doing some maths, the 4085 clusters is just the recomendation done by Microsoft, but as I show you the filesystems allow other etensions :-) Obviously, for such small filesystems is way better to use FAT12 or also the original and almost unknown (and unsupported) FAT8...

By the way, according to my calcs, 4085 clusters is the quantity needed by a 2MB filesystem using 1 sector per cluster (16 sectors for the FAT).

You misunderstand, the cluster count is how Windows' filesystem driver determines which version of FAT to use. The labeled FAT version is completely ignored.

from node-mkfat.

Interesting link :-) I've read before similar things but not in such
detail. Anyway, what it says is not that they could not be created, but
instead that they should be awoided because Windows will not be capable to
detect the correct sizes. I find it good to have this limits set by default
and add a flag to override them, and also having some docs about the
limited and real values would be good, since I've not found any info about
that and from the sites I've seen mostly that values are taken as a fact of
faith...

El 18/11/2016 10:19 PM, "sbuller" [email protected] escribió:

I was just doing some maths, the 4085 clusters is just the recomendation
done by Microsoft, but as I show you the filesystems allow other etensions
:-) Obviously, for such small filesystems is way better to use FAT12 or
also the original and almost unknown (and unsupported) FAT8...

By the way, according to my calcs, 4085 clusters is the quantity needed by
a 2MB filesystem using 1 sector per cluster (16 sectors for the FAT).

You misunderstand, the cluster count is how Windows' filesystem driver
determines which version of FAT to use. The labeled FAT version is
completely ignored
https://coriolis-systems.com/support/2015/8/when-fat16-not-fat16.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAgfvvfVU_E1NqkD0gcUtF-uNQ8WLUZ4ks5q_hZxgaJpZM4KwOOx
.

from node-mkfat.

Anyway, what it says is not that they could not be created, but instead that they should be awoided because Windows will not be capable to detect the correct sizes.

Not so. It has nothing to do with detecting correct size. It's about how it's read. Consider the spec, page 10,

This string is informational only and does not determine the FAT type

and in particular pages 14 & 15.

The FAT type is determined solely by the count of clusters on the volume (CountOfClusters).

I can't find a great specific quote, but this isn't just an opinion in the spec. This is also how filesystem drivers are written. If it has less than 4085 clusters, then the driver will interpret it as FAT12, regardless of your intentions.

from node-mkfat.

OSDev also weighs in on the matter.

from node-mkfat.

Here's someone who didn't know, or ignored the advice.

from node-mkfat.