[exfat-builder] Helps add exFAT support to the Humax.

that's very odd! I was sure that I had seen it on the Humax, but when I checked mine this evening it wasn't there, hence my earlier comment.

That was because I checked /sbin, instead of /mod/sbin, sigh :)

thanks much af123 for the new pkg.

As to the drive problem: for my colleague, the issue was that it would not auto-mount. He could mount it manually, and it worked perfectly.

I will get him to try the new pkg. thanks again...
 
For those following along...

It looks like my friend's problems with his exFAT stick not being automatically mounted by the Humax were caused by him using the entire device for the filesystem, rather than a partition.

i.e. he was using /dev/sdb (say), rather than /dev/sdb1.

One might argue that this is a Hummy bug: it does mount and work fine with the whole device fs, just won't auto-mount it. But it's hardly a big deal.

We also found that such a stick would not work at all in a Mac, which was the main reason for him using exFAT over e.g. ext2. Whereas the Mac was happy with the fs on a partition, of course.


One final note: the Humax doesn't seem to read the filesystem label, for exFAT, so the fs gets mounted as "drive2", rather than "mystick" etc. Again, hardly a huge deal...
 
I didn't know you could create a file system without its parameters being stored in some kind of partition table. Even if there is only one partition, hence occupying the whole device, there should still be a partition table.
 
Black Hole said:
I didn't know you could create a file system without its parameters being stored in some kind of partition table. Even if there is only one partition, hence occupying the whole device, there should still be a partition table.
Click to expand...

I don't see any reason for that to be the case. There are no "filesystem parameters" in a partition table: the latter just stores the start and length of a partition, which is a container, and which could have anything in it. There is a per-partition "type" field, in e.g. MBR-format partition tables, and it can cause odd problems if it's wrong, but it's just a marker, and many things ignore it.

If you are not interested in boot code in sector 0, nor in partitions, I don't see any reason to use a partition table. For example if you're using the entire disk as a crypto container, or a swap device. That said, I believe filesystem utilities may skip the very beginning of the device, even if given the whole device.

Certainly, you can do this on Linux, and it works perfectly: i.e. mkfs on a whole-device device link, rather than a per-partition link. But with the caveats in my post above, it's clearly not a great idea, at least for filesystems.
 
Black Hole said:
I didn't know you could create a file system without its parameters being stored in some kind of partition table. Even if there is only one partition, hence occupying the whole device, there should still be a partition table.
Click to expand...
How do you think floppy disks worked then?
 
Any operating system has to be told what the structure of the disk is (and a UPD is treated as another form of disk). It can make an assumption, but then the assumption can be wrong - as here. The usual assumption is that there will be some kind of data block located in a standard place which then describes how the mass storage is to be accessed. Not adhering to that standard risks incompatibility - as here. Without some kind of partition table, how does Linux even know to access the storage as exFAT? Maybe you have to tell it.

As far as floppies went - how often were they compatible across operating systems?
 
Partition tables don't (necessarily) tell you the filesystem type, as you've already been told. But it's pointless trying to explain as you're clearly out of your depth on this occasion.

And I could perfectly well read a FAT12 floppy written on DOS 2.0 on Win7 or anything in between or subsequent. Stop blathering.
 
prpr said:
Partition tables don't (necessarily) tell you the filesystem type, as you've already been told.
Click to expand...
Have I? Where? I must have missed that.

So how does (say) a Linux OS presented with (say) an Ext3 file system written to the whole of a block device without any preamble, know that it is an Ext3 file system and not an exFAT file system? How does it know it is a crypto-container or a swap file, and treat them accordingly? Logically there has to be some kind of standardised communication of those facts, and as far as I'm concerned it doesn't matter whether you call that an MBR or a partition table or a GPT... it still has to be standardised and every operating system you want it to be compatible with has to know to look at it. If you rely on trying to detect the type of file system (or whatever) using just the characteristics of what's on the block device, there is always a chance that something will come along that looks like something else but isn't.

Just because Linux can create a file system with none of the standardised means of communication doesn't mean it should, or if it does it ought to flag up some kind of warning that the file system thus created won't be compatible with other devices (much like what happens if you don't "finalise" a CDR). You don't need to convince me it's a good idea to do anything else - try convincing a user who's just been bitten by it.
 
Black Hole said:
Any operating system has to be told what the structure of the disk is (and a UPD is treated as another form of disk). It can make an assumption, but then the assumption can be wrong - as here. The usual assumption is that there will be some kind of data block located in a standard place which then describes how the mass storage is to be accessed. Not adhering to that standard risks incompatibility - as here. Without some kind of partition table, how does Linux even know to access the storage as exFAT? Maybe you have to tell it.
Click to expand...

quick answer: yes, you have to tell it. That is what the field in /etc/fstab is for, and that is set up manually. Or, you manually call the fs-specific mount utility, e.f. mount_exfat

there is an alternative: the Linux kernel can use the heuristics as in blkid(1), to guess at the filesystem type. It does this by trying lots of different possiblities, for all the fs types it has support for, and trying them, and/or looking for filesystem "magic numbers", i.e. binary code patterns at the start of the <thing> to see if they match its list of known fs magic numbers.
 
Black Hole said:
So how does (say) a Linux OS presented with (say) an Ext3 file system written to the whole of a block device without any preamble, know that it is an Ext3 file system and not an exFAT file system? How does it know it is a crypto-container or a swap file, and treat them accordingly? Logically there has to be some kind of standardised communication of those facts, and as far as I'm concerned it doesn't matter whether you call that an MBR or a partition table or a GPT... it still has to be standardised and every operating system you want it to be compatible with has to know to look at it. If you rely on trying to detect the type of file system (or whatever) using just the characteristics of what's on the block device, there is always a chance that something will come along that looks like something else but isn't.

Just because Linux can create a file system with none of the standardised means of communication doesn't mean it should, or if it does it ought to flag up some kind of warning that the file system thus created won't be compatible with other devices (much like what happens if you don't "finalise" a CDR). You don't need to convince me it's a good idea to do anything else - try convincing a user who's just been bitten by it.
Click to expand...

Firstly, there is a preamble, in that ext3 has a magic number at its start, which identifies it as such.

As above, it doesn't have to know: generally if a fs is listed in /etc/fstab, it is common to list there its type. So the kernel does not need to guess. But, again, you can let it guess if you prefer, and that is how you can mount a disk without it being in /etc/fstab or using an fs-specific mount command.

The fs type field in the partition table, if present, is not reliable. However, it can cause problems if not set correctly, especially on non-Linux platforms (e.g Mac, where it makes the disk unrecognisable).

However, I do agree that it's perhaps not wise to use the whole device for a filesystem - rather than a partition - at least not these days, as it seems that some things do rely on the partition table type field.

your general point: "how does it know?" - you are supposed to tell it. In the old days, we did not have all this new-fangled auto-mounting guesswork nonsense: you were expected to know what was on your disks, and you were expected to tell the kernel how to handle it.

It's ironic: your conclusions are reasonable, given modern OS behaviour, but some of us old timers may consider it incorrect :)
 
Black Hole said:
So what sets up fstab? Something has to.
Click to expand...

The sysadmin sets up fstab, and they also set up the disks. this is how it used to be.

For an unknown disk, one might cautiously mount it RO, if the kernel had the guesswork nonsense in it, then see what it thinks it's found, and whether the mounted fs looks resonable. then unmount it, and put it in the fstab.

that's seems rather quaint these days, but that's what we used to do. Well, I did...
 
Black Hole said:
Just because Linux can create a file system with none of the standardised means of communication doesn't mean it should, or if it does it ought to flag up some kind of warning that the file system thus created won't be compatible with other devices (much like what happens if you don't "finalise" a CDR). You don't need to convince me it's a good idea to do anything else - try convincing a user who's just been bitten by it.
Click to expand...

to put it another way: not everyone considers the partition table fs type flag a "standardised means of communication." Well, I don't, at least :)

It was once quite common to put filesystems on entire disks, rather than on a partition. It is still common to do this for crypto containers. This can be done without a partition table even existing.

Nowadays, it would seem to create problems, so I agree it is better to use a single partition, and to set the par-partition table fs type flag to a reasonable value, especially if wanting to inter-operate across different OS (e.g. exFAT on Linux/Mac).

Note that this partition table flag does not uniquely indicate the filesystem type, in all cases. e.g. for exFAT it is normally set to '7', which indicates: "HPFS/NTFS/exFAT". So you would still not know which fs-specific code to use.
 
Last edited:
See, that is my point. These days people who use computers (ie just about everybody) are not sysadmins. They expect things to be plug-and-play. Your typical mainstream desktop OS will expect to find standardised markers when it is suddenly presented with an unknown mass storage unit (be that USB, SATA, PATA...), so that it can implement plug-and-play. Having to manually set up fstab may be possible in *UNIX, but I wouldn't know where to begin on a Windows system.

It didn't even cross my mind that one might bypass the fdisk stage of preparation, and (unless you are doing it manually on the command line) the tools don't let you.
 
Partition tables are archaic really. The disks in my computer only have one partition on them and that contains an LVM physical volume. The (several) filesystems themselves are made on spaces called logical volumes constructed out of space assigned out of volume groups which are themselves constructed out of the physical volumes (and the filesystem can be spread across different partitions and even different drives, seamlessly). The filesystem has NOTHING to do with any partition table. If it did, the above would not work.
My point about floppies was made to try and convince you that partition tables don't hold details about what they contain and are therefore not necessary. How did floppies ever work without a partion table? The answer is that a partition table is not necessary for any filesystem on any medium, yet seemingly you still refuse to accept it. Maybe if you read up on LVM and worked out how it worked, you might be convinced, but I suspect not.
 
prpr said:
Partition tables are archaic really. The disks in my computer only have one partition on them and that contains an LVM physical volume.
Click to expand...
Similarly for my computers running ZFS. It's perfectly commonplace, particularly in the entireprise sphere, to use a disk directly as a block device and not bother with partitioning. Incidentally, the raw disk block device is exactly what fdisk reads from and writes to.
 
of course, ZFS and LVM are both volume managers themselves, so it makes perfect sense for them to use whole devices, not partitions.

It may not be quite as sensible to use a plain filesystem directly over a whole device, these days, without regard to a partition table.

To recap, I found the following problems when testing exFAT on a whole-disk device:

- Humax does not auto-mount the fs; it will mount manually, and work correctly

- Mac OSX refuses to recognise the device at all

whereas both worked perfectly when using a single partition.

It may be that the problems were not the lack of a partition table, but possibly conflicting values in a stale, but not overwritten previous partition table. I'm not entirely sure whether a previous partition table had been cleared, when I was using it as a whole-disk device. I believe that mkfs may skip the initial area, where a partition table would be, even when used with the whole-disk device.

As far as auto-recognising is concerned, at least, it would seem clear that the OS cannot differentiate between a whole-disk device fs that happens to include within it a stale partition table, and a single-partiton fs. Which is reasonable, and is (part of) Black Hole 's point :)

I should test again, having first overwritten the partition table.
 
Ezra Pound said:
Does the note in the WiKi need removing if version 1.2.3 is pre-built?
Click to expand...
I'm now in a position to answer my own question, the WiKi notes for Exfat-Builder will remain on the WiKi as the complied version is contained in a separate CFW packaged called 'Exfat', WiKi link HERE, I did think that maybe the new package might replace the old one
 
You must log in or register to reply here.
Back
Top