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.
--
** [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.
> 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*
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
>
> # 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
--
<[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
From: "H. Peter Anvin" <[email protected]>
> "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
Michael Rothwell wrote:
>
> From: "H. Peter Anvin" <[email protected]>
> > "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
--
<[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
H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: [email protected] (Rogier Wolff)
> In newsgroup: linux.dev.kernel
> >
> > # 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.
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.
--
** [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.
Rogier Wolff wrote:
>
> H. Peter Anvin wrote:
> > Followup to: <[email protected]>
> > By author: [email protected] (Rogier Wolff)
> > In newsgroup: linux.dev.kernel
> > >
> > > # 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.
>
> 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
--
<[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
On Sun, Apr 29, 2001 at 01:09:22PM -0700, H. Peter Anvin wrote:
> Rogier Wolff wrote:
> >
> > H. Peter Anvin wrote:
> > > Followup to: <[email protected]>
> > > By author: [email protected] (Rogier Wolff)
> > > In newsgroup: linux.dev.kernel
> > > >
> > > > # 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.
> >
> > 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?
He gave what he thought was a complete dump of the non-null bytes. The
obvious answer is that he's looking wrong. :)
Gregory Maxwell wrote:
> >
> > 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
--
<[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
H. Peter Anvin wrote:
> Rogier Wolff wrote:
> >
> > H. Peter Anvin wrote:
> > > Followup to: <[email protected]>
> > > By author: [email protected] (Rogier Wolff)
> > > In newsgroup: linux.dev.kernel
> > > >
> > > > # 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.
> >
> > 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?
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#
--
** [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.
Gregory Maxwell wrote:
> On Sun, Apr 29, 2001 at 01:09:22PM -0700, H. Peter Anvin wrote:
> > Rogier Wolff wrote:
> > >
> > > H. Peter Anvin wrote:
> > > > Followup to: <[email protected]>
> > > > By author: [email protected] (Rogier Wolff)
> > > > In newsgroup: linux.dev.kernel
> > > > >
> > > > > # 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.
> > >
> > > 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?
>
> 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(......
%
--
** [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.
Rogier Wolff wrote:
> >
> > 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.
>
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
--
<[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
H. Peter Anvin wrote:
> Gregory Maxwell wrote:
> > >
> > > 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...
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.
--
** [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.
Rogier Wolff wrote:
>
> H. Peter Anvin wrote:
> > Gregory Maxwell wrote:
> > > >
> > > > 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...
>
> 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
--
<[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
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...]
> Btw, the root dir contains 512 entries.
> Just from the dump.
Jep.
> (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.
--
** [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.
H. Peter Anvin wrote:
> Rogier Wolff wrote:
> > 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.
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.
--
** [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
On Sun, Apr 29, 2001 at 10:45:41PM +0200, Rogier Wolff wrote:
> H. Peter Anvin wrote:
>
> > Rogier Wolff wrote:
>
> > > 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.
>
> 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.
>
> --
> ** [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/
--
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
Moin,
> -----Original Message-----
> From: mirabilos [mailto:[email protected]]
> Sent: Sunday, April 29, 2001 1:07 AM
> To: [email protected]; Rogier Wolff
> Subject: Re: Sony Memory stick format funnies...
>
>
> 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*
>
> I didnt look further but IMO it must be PARTITIONED???
> (I'd start the partition at +1 rather than +0x27)
>
Right, it is partitioned. And the dcim-dir is created by the camera during
formatting...
Olli
--
Die Wahrheit liegt irgendwo da drau?en...