Sony Memory stick format funnies...
Hi,
I have a Sony memory stick in my system. When I display all the interesting (i.e. not all 0xff and not all 0x00 data), I see (on a recently formatted stick):
% hd /dev/hde | grep -v "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff" | grep -v "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 02 ................ 001c0 08 00 01 07 d0 dd 27 00 00 00 d9 ee 01 00 00 00 ....P]'...Yn.... 001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 04e00 e9 00 00 20 20 20 20 20 20 20 20 00 02 20 01 00 i.. .. .. 04e10 02 00 02 00 00 f8 0c 00 10 00 08 00 27 00 00 00 .....x......'... 04e20 d9 ee 01 00 00 00 29 00 00 00 00 00 00 00 00 00 Yn....)......... 04e30 00 00 00 00 00 00 46 41 54 31 32 20 20 20 00 00 ......FAT12 .. 04ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 05000 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 06800 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 08000 4d 45 4d 53 54 49 43 4b 49 4e 44 03 00 00 00 00 MEMSTICKIND..... 08010 00 00 00 00 00 00 4f 4c b7 28 00 00 00 00 00 00 ......OL7(......
%
However, when I mount the stick on /mnt/d1 I see:
# l /mnt/d1 total 16 drwxr-xr-x 512 root root 16384 Mar 24 17:26 dcim/ -r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind* #
Where the *(&#$%& does that "dcim" directory come from????
Roger.
Signature · 4 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots.
Quoted 1 line
001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 02
................
Quoted 1 line
001c0 08 00 01 07 d0 dd 27 00 00 00 d9 ee 01 00 00 00
....P]'...Yn....
Quoted 1 line
001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
..............U*
Quoted 1 line
04e00 e9 00 00 20 20 20 20 20 20 20 20 00 02 20 01 00 i.. ..
..
Quoted 1 line
04e10 02 00 02 00 00 f8 0c 00 10 00 08 00 27 00 00 00
.....x......'...
Quoted 1 line
04e20 d9 ee 01 00 00 00 29 00 00 00 00 00 00 00 00 00
Yn....).........
Quoted 1 line
04e30 00 00 00 00 00 00 46 41 54 31 32 20 20 20 00 00 ......FAT12
..
Quoted 1 line
04ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
..............U*
I didnt look further but IMO it must be PARTITIONED??? (I'd start the partition at +1 rather than +0x27)
No, the directory is not on the disk, and I've been DEBUG.COMing FAT drives since I was 9 years old.
-mirabilos
Followup to: <[email protected]> By author: [email protected] (Rogier Wolff) In newsgroup: linux.dev.kernel
Quoted 9 lines
# l /mnt/d1 total 16 drwxr-xr-x 512 root root 16384 Mar 24 17:26 dcim/ -r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind* #Where the *(&#$%& does that "dcim" directory come from????
"dcim" probably stands for "digital camera images". At least Canon digital cameras always put their data in a directory named dcim.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 10 lines · H. Peter Anvin
Followup to: <[email protected]> By author: [email protected] (Rogier Wolff) In newsgroup: linux.dev.kernelQuoted 7 lines
# l /mnt/d1 total 16 drwxr-xr-x 512 root root 16384 Mar 24 17:26 dcim/ -r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind* #
Quoted 5 lines
Quoted 2 lines
Where the *(&#$%& does that "dcim" directory come from????
"dcim" probably stands for "digital camera images". At least Canon digital cameras always put their data in a directory named dcim.
Yes. I know. Seems to be standard. The stick is for my Sony camera.
However, the question is: how in **** is the Linux kernel seeing that directory while it's not on the stick? (the root directory has one MEMSTICK.IND file, and nothing else!)
Roger.
Signature · 4 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots.
Quoted 15 lines · Rogier Wolff
Quoted 13 lines · H. Peter Anvin
Followup to: <[email protected]> By author: [email protected] (Rogier Wolff) In newsgroup: linux.dev.kernelQuoted 9 lines
# l /mnt/d1 total 16 drwxr-xr-x 512 root root 16384 Mar 24 17:26 dcim/ -r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind* #Where the *(&#$%& does that "dcim" directory come from????
Quoted 9 lines
Quoted 2 lines
"dcim" probably stands for "digital camera images". At least Canon digital cameras always put their data in a directory named dcim.
Yes. I know. Seems to be standard. The stick is for my Sony camera.
However, the question is: how in **** is the Linux kernel seeing that directory while it's not on the stick? (the root directory has one MEMSTICK.IND file, and nothing else!)
I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope?
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 26 lines · H. Peter Anvin
Quoted 15 lines · Rogier Wolff
Quoted 13 lines · H. Peter Anvin
Followup to: <[email protected]> By author: [email protected] (Rogier Wolff) In newsgroup: linux.dev.kernelQuoted 9 lines
# l /mnt/d1 total 16 drwxr-xr-x 512 root root 16384 Mar 24 17:26 dcim/ -r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind* #Where the *(&#$%& does that "dcim" directory come from????
Quoted 9 lines
Quoted 2 lines
"dcim" probably stands for "digital camera images". At least Canon digital cameras always put their data in a directory named dcim.
Yes. I know. Seems to be standard. The stick is for my Sony camera.
However, the question is: how in **** is the Linux kernel seeing that directory while it's not on the stick? (the root directory has one MEMSTICK.IND file, and nothing else!)
Quoted 5 lines
I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope?
Yes, I realize. That's why I gave the whole dump in the first Email.
These are all lines of 16 bytes that do not contain only zeroes or only 0xff's.
% hd /dev/hde | grep -v "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff" | grep -v "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 02 ................ 001c0 08 00 01 07 d0 dd 27 00 00 00 d9 ee 01 00 00 00 ....P]'...Yn.... 001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 04e00 e9 00 00 20 20 20 20 20 20 20 20 00 02 20 01 00 i.. .. .. 04e10 02 00 02 00 00 f8 0c 00 10 00 08 00 27 00 00 00 .....x......'... 04e20 d9 ee 01 00 00 00 29 00 00 00 00 00 00 00 00 00 Yn....)......... 04e30 00 00 00 00 00 00 46 41 54 31 32 20 20 20 00 00 ......FAT12 .. 04ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 05000 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 06800 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 08000 4d 45 4d 53 54 49 43 4b 49 4e 44 03 00 00 00 00 MEMSTICKIND..... 08010 00 00 00 00 00 00 4f 4c b7 28 00 00 00 00 00 00 ......OL7(......
%
And I wholeheartedly agree that the kernel shouldn't have much imagination and such. That's why I was so surprised......
Roger.
P.S.
In private I will confess to have edited the cut-and-paste from a window where I used the hexdump I prepared and have stored on a 26Mb per second disk:
tmp/memstick> grep -v "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff" formatted.img.hd | grep -v "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 02 ................ 001c0 08 00 01 07 d0 dd 27 00 00 00 d9 ee 01 00 00 00 ....P]'...Yn.... 001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 04e00 e9 00 00 20 20 20 20 20 20 20 20 00 02 20 01 00 i.. .. .. 04e10 02 00 02 00 00 f8 0c 00 10 00 08 00 27 00 00 00 .....x......'... 04e20 d9 ee 01 00 00 00 29 00 00 00 00 00 00 00 00 00 Yn....)......... 04e30 00 00 00 00 00 00 46 41 54 31 32 20 20 20 00 00 ......FAT12 .. 04ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 05000 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 06800 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 08000 4d 45 4d 53 54 49 43 4b 49 4e 44 03 00 00 00 00 MEMSTICKIND..... 08010 00 00 00 00 00 00 4f 4c b7 28 00 00 00 00 00 00 ......OL7(......
tmp/memstick>
but just to be sure, I actually issued the command I pretended to have given on the REAL thing, and got:
adder wolff/memstick# hd /dev/hde | grep -v "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff" | grep -v "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 02 ................ 001c0 08 00 01 07 d0 dd 27 00 00 00 d9 ee 01 00 00 00 ....P]'...Yn.... 001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 04e00 e9 00 00 20 20 20 20 20 20 20 20 00 02 20 01 00 i.. .. .. 04e10 02 00 02 00 00 f8 0c 00 10 00 08 00 27 00 00 00 .....x......'... 04e20 d9 ee 01 00 00 00 29 00 00 00 00 00 00 00 00 00 Yn....)......... 04e30 00 00 00 00 00 00 46 41 54 31 32 20 20 20 00 00 ......FAT12 .. 04ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 05000 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 06800 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 08000 4d 45 4d 53 54 49 43 4b 49 4e 44 03 00 00 00 00 MEMSTICKIND..... 08010 00 00 00 00 00 00 4f 4c b7 28 00 00 00 00 00 00 ......OL7(......
adder wolff/memstick#
which looked similar enough that I decided not to bother pasting that output into the Email.
adder wolff/memstick# l /mnt/d1
total 16
drwxr-xr-x 512 root root 16384 Mar 24 17:26 dcim/
-r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind*
adder wolff/memstick# uptime
10:16pm up 6 days, 12:29, 1 user, load average: 0.00, 0.00, 0.00
adder wolff/memstick#
Signature · 4 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots.
Quoted 7 lines · Rogier Wolff
Quoted 6 lines
I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope?
Quoted 5 lines
Yes, I realize. That's why I gave the whole dump in the first Email.
These are all lines of 16 bytes that do not contain only zeroes or only 0xff's.
I can't test kernel behaviour with a hexdump! I think the first thing you should do is dd your entire thing to a file, mount it loopback, and see if the behaviour reoccurs or not using the file. Then you may want to consider posting the binary somewhere.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 26 lines · H. Peter Anvin
Quoted 15 lines · Rogier Wolff
Quoted 13 lines · H. Peter Anvin
Followup to: <[email protected]> By author: [email protected] (Rogier Wolff) In newsgroup: linux.dev.kernelQuoted 9 lines
# l /mnt/d1 total 16 drwxr-xr-x 512 root root 16384 Mar 24 17:26 dcim/ -r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind* #Where the *(&#$%& does that "dcim" directory come from????
Quoted 9 lines
Quoted 2 lines
"dcim" probably stands for "digital camera images". At least Canon digital cameras always put their data in a directory named dcim.
Yes. I know. Seems to be standard. The stick is for my Sony camera.
However, the question is: how in **** is the Linux kernel seeing that directory while it's not on the stick? (the root directory has one MEMSTICK.IND file, and nothing else!)
Quoted 5 lines
I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope?
He gave what he thought was a complete dump of the non-null bytes. The obvious answer is that he's looking wrong. :)
Quoted 27 lines · Gregory Maxwell
Quoted 26 lines · H. Peter Anvin
Quoted 24 lines · Rogier Wolff
Quoted 10 lines · H. Peter Anvin
Followup to: <[email protected]> By author: [email protected] (Rogier Wolff) In newsgroup: linux.dev.kernelQuoted 7 lines
# l /mnt/d1 total 16 drwxr-xr-x 512 root root 16384 Mar 24 17:26 dcim/ -r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind* #Quoted 5 lines
Quoted 2 lines
Where the *(&#$%& does that "dcim" directory come from????
"dcim" probably stands for "digital camera images". At least Canon digital cameras always put their data in a directory named dcim.
Yes. I know. Seems to be standard. The stick is for my Sony camera.
However, the question is: how in **** is the Linux kernel seeing that directory while it's not on the stick? (the root directory has one MEMSTICK.IND file, and nothing else!)
Quoted 8 lines
Quoted 5 lines
I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope?
He gave what he thought was a complete dump of the non-null bytes. The obvious answer is that he's looking wrong. :)
You think the kernel decodes the 1bit per 16 bytes into a "dcim" directory? (I filtered out both the lines with 16 0xff bytes as well as those with 16 0x00 bytes. That leaves one bit per 16 bytes that I didn't show in that Email)
Feel free to tell me what I'm doing wrong.... I'd like to know. I could hack the kernel to hexdump the blocks it gets from the disk. I know I can. I was hoping the linux-kernel crew would be able to tell me something obvious I was missing or that we're on to something odd...)
Roger.
% hd /dev/hde | grep -v "ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff" | grep -v "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 02 ................ 001c0 08 00 01 07 d0 dd 27 00 00 00 d9 ee 01 00 00 00 ....P]'...Yn.... 001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 04e00 e9 00 00 20 20 20 20 20 20 20 20 00 02 20 01 00 i.. .. .. 04e10 02 00 02 00 00 f8 0c 00 10 00 08 00 27 00 00 00 .....x......'... 04e20 d9 ee 01 00 00 00 29 00 00 00 00 00 00 00 00 00 Yn....)......... 04e30 00 00 00 00 00 00 46 41 54 31 32 20 20 20 00 00 ......FAT12 .. 04ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U* 05000 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 06800 f8 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 x............... 08000 4d 45 4d 53 54 49 43 4b 49 4e 44 03 00 00 00 00 MEMSTICKIND..... 08010 00 00 00 00 00 00 4f 4c b7 28 00 00 00 00 00 00 ......OL7(......
%
Signature · 4 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots.
Quoted 10 lines · Gregory Maxwell
Quoted 6 lines
I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope?
He gave what he thought was a complete dump of the non-null bytes. The obvious answer is that he's looking wrong. :)
Hence the "complete" part...
-=hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 8 lines · H. Peter Anvin
Quoted 7 lines · Gregory Maxwell
Quoted 6 lines
I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope?
Quoted 5 lines
Quoted 3 lines
He gave what he thought was a complete dump of the non-null bytes. The obvious answer is that he's looking wrong. :)
Hence the "complete" part...
OK.
The image of the disk (including partition table) is at:
ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz
It's 63kb and uncompresses to the 64Mb (almost) that it's sold as.
Roger.
Signature · 4 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots.
Quoted 16 lines · Rogier Wolff
Quoted 8 lines · H. Peter Anvin
Quoted 7 lines · Gregory Maxwell
Quoted 6 lines
I doubt the kernel is seeing it without it being there (it doesn't have much imagination.) However, it may very well be there in a funny manner. You do realize, of course, that it's pretty much impossible for us to help you answer that question without a complete dump of the filesystem on hand, I hope?
Quoted 5 lines
Quoted 3 lines
He gave what he thought was a complete dump of the non-null bytes. The obvious answer is that he's looking wrong. :)
Hence the "complete" part...
Quoted 8 lines
OK.
The image of the disk (including partition table) is at:
ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz
It's 63kb and uncompresses to the 64Mb (almost) that it's sold as.
And on at least this kernel (2.4.0) there is nothing funny about it:
: tazenda 13 ; ls -l /mnt
total 0
-r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind*
: tazenda 14 ;
Mounting msdos, vfat or umsdos, no change.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 9 lines · H. Peter Anvin
Quoted 6 lines · Rogier Wolff
The image of the disk (including partition table) is at:
ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz
It's 63kb and uncompresses to the 64Mb (almost) that it's sold as.
Quoted 8 lines
And on at least this kernel (2.4.0) there is nothing funny about it:
: tazenda 13 ; ls -l /mnt
total 0
-r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind*
: tazenda 14 ;Mounting msdos, vfat or umsdos, no change.
OK. I rebooted the laptop:
Linux version 2.2.13 ([email protected]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Nov 8 15:37:25 CET 1999
which seems to have cleared it. Somehow that directory was still cached somewhere (not in the buffer cache) from when there were images on the memory stick.
So, I'm suspecting a dcache bug, that allows something to stay over after swapping a removable media device.... And all this is irrelevant as this was on a very old kernel. Sorry to have been wasting your time.
Roger.
Signature · 4 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots.
I've seen something similar with USB memory stick devices... they don't seem to report a media change in a way that the VFS layer will understand.
I think this deserves some _serious_ debugging, personally, as this is going to come back to haunt us over and over again with some types of memory stick (and possibly other) media devices.
I'd do it, but I don't have a memory stick reader. Rogier, can you volunteer some time for this?
Matt
Quoted 47 lines · Rogier Wolff
Quoted 9 lines · H. Peter Anvin
Quoted 6 lines · Rogier Wolff
The image of the disk (including partition table) is at:
ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz
It's 63kb and uncompresses to the 64Mb (almost) that it's sold as.
Quoted 8 lines
And on at least this kernel (2.4.0) there is nothing funny about it:
: tazenda 13 ; ls -l /mnt
total 0
-r-xr-xr-x 1 root root 0 May 23 2000 memstick.ind*
: tazenda 14 ;Mounting msdos, vfat or umsdos, no change.
OK. I rebooted the laptop:
Linux version 2.2.13 ([email protected]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Nov 8 15:37:25 CET 1999
which seems to have cleared it. Somehow that directory was still cached somewhere (not in the buffer cache) from when there were images on the memory stick.
So, I'm suspecting a dcache bug, that allows something to stay over after swapping a removable media device.... And all this is irrelevant as this was on a very old kernel. Sorry to have been wasting your time.
Roger.
Signature · 9 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 7 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver S: Another stupid question? G: There's no such thing as a stupid question, only stupid people. -- Stef and Greg User Friendly, 7/15/1998
Btw, the root dir contains 512 entries.
Just from the dump.
(I would let the partition start at sector ptabl+1, not wasting so much space... but M$ fdisk.exe neither does.) -mirabilos
mirabilos wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
Quoted 2 lines
Btw, the root dir contains 512 entries.
Just from the dump.
Jep.
Quoted 2 lines
(I would let the partition start at sector ptabl+1, not wasting so much space... but M$ fdisk.exe neither does.)
This was formatted by my Sony DSC505V.
Roger.
Signature · 4 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots.
From: "H. Peter Anvin" <[email protected]>
Quoted 2 lines
"dcim" probably stands for "digital camera images". At least Canon digital cameras always put their data in a directory named dcim.
Makes sense. FAT's root directory is limited in the number of entries it can contain, to something like 32. Cameras can easily produce more than that number of images.
-M
Quoted 9 lines · Michael Rothwell
From: "H. Peter Anvin" <[email protected]>
Quoted 2 lines
"dcim" probably stands for "digital camera images". At least Canon digital cameras always put their data in a directory named dcim.
Makes sense. FAT's root directory is limited in the number of entries it can contain, to something like 32. Cameras can easily produce more than that number of images.
Usually 224.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt