Re: [Mtools] Reading label from a large capacity memory card

[Simon Large]

Alain Knaff wrote:
> Simon Large wrote:
>> Hi David,
>> 
>> Thanks for your reply and sorry for my lack of response. Stupid
>> Exchange Server throws all Bcc mail in the bin, so your mail never
>> reached me. 
> 
> So, why again do you use Exchange?... :-)

Sorry, I'm stuck with it in work :-(

>>> I am try to read the volume label from a memory card. 2 questions:
>>> 
>>> 1. Using mlabel -s a: with a 4GB card I get the message:
>>> "Big disks not supported on this architecture."
> 
> The reason for this is that the compiler that you are using on that
> architecture (ARM?) does not have a data type (such as long long) big
> enough to support offsets found on "big" disks (larger than 2G).  
> 
> The following data types are tried:
>       off_t
>       loff_t
>       offset_t
>       long long
> 
> If none of these are 64 bit capable, then the maximal allowable size
> is 2G (the biggest amount representable in a signed 32 bit integer). 
> 
> If there is another data type capable of holding more than 32 bits,
> you may add it to llong.h by replacing long long in lines 35 and 36: 
> 
> #  define MT_OFF_T long long
> #  define MT_SIZE_T unsigned long long

I finally got round to digging into this. My toolchain (arm-linux-gcc)
does support 64 bit integers. The problem is that it uses lseek64()
rather than llseek() so the check in llong.h should be looking for
HAVE_LSEEK64 as well as HAVE_LLSEEK. The corresponding type for
lseek64() is off64_t.

But after putting that in the problem still remains. For my 8GB memory
card the XdfOpen() call succeeds and maxsize is set to max_off_t_31,
which seems to be where the limit lies.

However, it seems that in init.c the value of maxsize is not
initialized. If the device opens as a floppy or XDF then maxsize is
always set to max_off_t_31, but if it falls back to SimpleFileOpen(),
then maxsize just has whatever random value was there when fs_init()
starts. Sounds like a bug to me.

Not sure where to go from here.

> In order to test out this hypothesis, try using mlabel on the same
> card on a PC with an Intel processor. 
> 
> Theoretically, I could "hand-design" such a type using a struct, but
> then the problem would still exist of passing such offsets to the
> kernel, because its lseek would not support these size either.  
> 
> If all you need is mlabel, you might get by by commenting out the
> check in 
> init.c:
> if (tot_sectors >= (maxSize >> This->sectorShift)) {
>          fprintf(stderr, "Big disks not supported on this
>          architecture\n"); exit(1);
> }
> 
> becomes:
> 
> if (tot_sectors >= (maxSize >> This->sectorShift)) {
>           tot_sectors = (maxSize >> This->sectorShift); }

Yes, that works. But did you mean:
        tot_sectors = (maxSize >> This->sectorShift) - 1;

> Indeed, for mlabel this would probably be good enough, as it merely
> needs to read the root directory, which would usually be at the
> beginning of the partition. Theoretically a FAT32 could have it
> anywhere, but usually, that's rather unlikely.   
> 
> [...]
>>> 2. I only ever want to read the volume label. I don't need to write
>>> anything to the card, or use any other mtools great features (sorry,
>>> nothing against mtools). Is there an easy way to make a cut down app
>>> which just does this? I am cross compiling for ARM and it has to go
>>> onto 
> 
> The (short) label is stored in the boot sector starting at byte
> position 43. 
> 
> Try using the following command to read the (short) volume label.
> 
> dd bs=1 skip=43 count=11 if=/dev/mmvblk0p1 2>/dev/null
> 
> where img.bin is the image whose label you want to read.
> 
> A small equivalent C program could achieve the same.
> 
> For long labels (more than 11 characters), it gets a little bit more
> complicated, because there it is stored in the root directory. 

Unfortunately it always seems to get stored in the root directory by
Windows, even though the name is forced to 1 chars uppercase. Location
0x47 always has "NO NAME    ". Maybe I will look at that another day.

Please could you CC me in any reply,

Thanks,

Simon