LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   USB Flash memory writing problem (https://www.linuxquestions.org/questions/linux-hardware-18/usb-flash-memory-writing-problem-135838/)

tajuton 01-17-2004 05:40 PM

USB Flash memory writing problem
 
I have a nice USB Flash Memory from MSI (MS-5511 Mega Stick)

The problem is that MS-5511 file written in Linux disappears when
device is connected back to USB.



My devices are:

Linux Redhat 8.0, kernel 2.4.18-14


Windows XP pro (English)


MS-5511 Firmware Version Details:

Boot Manager 002.412.001

USB Mass Storage 002.040.000

Player 002.040.000

Resource Manager 002.040.000

Chip Version 3410



Procedure in Linux



1. Connect MS-5511 to USB

2. mount -tvfat /dev/sda1 /mnt/MSI

3. cp file.mp3 /mnt/MSI/.

4. umount /mnt/MSI

5. disconnect MS-5511 from USB cable

6. file.mp3 can be listen from MS-5511

7. connect MS-5511 to USB cable

8. mount -tvfat /dev/sda1 /mnt/MSI

9. file.mp3 is non-existent



File disappears as well in WIN XP. Looks like MS-5511 device
disconnecting is critical function. In case I write file into
MS-5511 device in Linux, umount, and reboot computer (without
disconnecting MS-5511 from USB) and start it again in WIN XP
mode, data written in Linux can be read in WIN XP.



I made also following experiment which shows that Linux write
is probably the problem:



1. copy file win.txt to MS-5511 (in WIN XP)

2. boot to Linux

3. edit file win.txt in MS-5511 (in Linux)

4. create file lin.txt into MS-5511 (in Linux)

5. boot to WIN XP (without disconnecting MS-5511)

6. edit file lin.txt (in WIN XP)

7. disconnect MS-5511

8. connect MS-5511

9. -> both win.txt and lin.txt have disappeared.




Does anybody know how Linux write differs from WIN (or any solution for the problem)? I have not (at least yet) got answer from manufacturer - and actually I don't wait very much help from their side, because they clearly tell that only Windows versions are supported. Please help Linux to beat Windows!

Juha.

hollerith 01-17-2004 05:45 PM

Hollerith uses:

mount -t msdos /dev/sda1 /mnt/removable

tajuton 01-18-2004 06:37 AM

Sorry, I forgot to mention I've tried that already, it didn't help.

zahid@allbd.com 01-27-2004 07:19 AM

After fresh boot: Works Once Only
 
I'm using Flash Drive 64MB (supports USB V1.1) in RedHat 9.0 with gnome

After a fresh reboot when I put my USB Memory Stick in USB port
#mount /dev/sda1 /mnt/usbstick
It works perfectly, I can copy, remove, whatever Ilike to do in the drive.
I can also
#umount /mnt/usbstick


But When I unplug and plug again the storage and run the mount command as earlier
.. this time it does not work and hangs on. As a result I have to reboot the system to access my USB Flash Memory.

Any one got problem like that?

hollerith 01-27-2004 06:43 PM

It should behave like a SCSI - its serial right? Definitely, /dev/sda1. Zahid, Windows has this problem, 'safe to uplug hardware' tray icon too. I don't think USB is a perfect hotswap. Unmounting the filesystem is different from removing the logical device so you can physically unplug the hardware maybe.

zahid@allbd.com 01-28-2004 01:23 AM

Okay.. let me check if it works this way.

imfred 02-08-2004 05:01 PM

I have that very same Mega Stick, have encountered the same problem and have come to a similar diagnosis:

Each time the Mega Stick is connected to an USB host, it performs a kind of "scandisk" on its file system (which removes "bad" files).
It seems the guys who wrote the firmware only tested their "scandisk" with windows-written files.

Solutions:
- write MSI and hope for a bug correction in the next firmware version,
- patch the linux fat code for use with the Mega Stick (I don't think changes would make to the official kernel tree, so it would be an unofficial patch),
- write a little program that "corrects" the file system after a linux write (would have to be launched after every umount but could be added in an umountmegastick.sh script)...

The first one is the best but I wonder if MSI would see it the same way (AFAIK it may even be a deliberate flaw, who knows?).
The second is the next-to-best but might not be as easy as the last one...


In order to find out what linux doesn't do as expected by the Mega Stick firmware I tried creating a file under windows and under linux and then diff hexdumps of the filesystem taken after each creation.

It seems the differences are located both in the FAT (chain termination code?) and in the folder entries.
I have not had time to investigate further yet, but I hope this problem will be solved soon.

imfred 02-12-2004 05:28 PM

Well, it seems my guess about chain termination code was correct. Windows uses 0xFFFF whereas linux uses 0xFFF8, which are both valid according to specifications I found on the internet.

However, the "scandisk" of the Mega Stick deletes every entry having 0xFFF8 as a termination code each time it is plugged on an USB port.

I have tried creating a file under linux then umount the filesystem, rewrite the 0xFFF8 termination code into 0xFFFF, unplug, replug and the file was still there...

I suppose the quickest way around this "bug" is to recompile the linux kernel (or at least the fat module) after having changed:
include/linux/msdos_fs.h:#define EOF_FAT16 0xFFF8
to
include/linux/msdos_fs.h:#define EOF_FAT16 0xFFFF

I don't think of any bad side effect this could have, however I am far from being an expert about the linux kernel: use at your own risks. I have tested this myself (though not thoroughly) and I can now write files to my Mega Stick that will not get deleted upon unplug/replug.


NB: I assumed the Mega Stick was formated in FAT16, which seems to be the default. Remember that this is just a quick "hack" and that the best solution would be for MSI to correct their "scandisk".

tajuton 02-18-2004 02:17 AM

Thanks,

looks like you've found the problem and a work around. I've tried to understand how file systems are written - looks like it would require some effort to learn it. Does anybody know a good tutorial for it?

Does anybody know why Linux FAT uses chain termination code 0xFFF8, even though Microsoft says they are using 0xFFFF?

I wrote to MSI about this problem (and your solution), no reply yet.


All times are GMT -5. The time now is 05:17 AM.