I’m having a rather bizarre problem with USB using the QNX 4.25 2011 release.
Boot the machine from hard drive (PATA).
Plug in a flash drive on a USB port.
Copy the hard drive to the flash drive.
At this point, everything is fine. chkfsys and dcheck both say the flash drive is okay.
Reboot, this time with a floppy.
Copy the flash drive contents back to a hard drive.
PROBLEM! At this point, some file are corrupted on the hard drive. Even stranger, some files are corrupted on the flash drive!
Notes:
a) I’m being careful not to overwrite .inodes or .bitmap in either direction.
b) We’ve tried numerous hard drives and several different flash drives.
c) Yes, the boot floppy is not PRECISELY the same as the hard drive. However, I also tried it once booting from a hard drive, and copying from the USB stick to a secondary hard drive.
d) On a related note, copying from primary to secondary works fine.
e) I have so far only tested this on one machine, so it could be purely hardware related. I’m working on getting another test machine up and going.
Small update: I have now tried this on a different machine and gotten the same result. How in the **** is the device I’m copying FROM getting corrupted?!?
You did initialize the stick with dinit? If drive was formatted as Fat 32 you would have problems.
After the copy operation is complete, you should be careful not to remove the stick until the cache is flushed. I’ve found that “sync” does not do what I expected it to do, wait until the cache is flushed.
Yes, I have properly formatted for QNX, in two different ways. A collegue of mine likes to dinit -hq /dev/hd1 and use it directly. This bugs me on several levels, so I fdisk /dev/hd1, remove all partitions, create a partition of type 77 that is (at most) 1024 cylinders, do a mount -p /dev/hd1, then dinit -hq /dev/hd1t77. Admittedly, his way is a lot less effort, but I just feel like it’s not the “right” way to do it. In any case, I have done both.
Two thoughts here. First, we’ve left the machine overnight to try to make sure all operations were complete. We’ve also done sync and umount. Nothing helps. Second, why would any of that matter reading FROM the flash? No matter what operations haven’t finished, it shouldn’t be writing ANYTHING to the flash, so even if I interrupt an operation the flash should still be fine.
Still baffled, but thanks for putting some thought into it.
Unless you’ve mount the flash to be read-only, just reading to it will modify its content, because the last access time will need to be updated. Fsys has an option to disable this feature (making it non-posix compliant), but it affects all partitions/devices.
Yanking a USB stick out while being updated is not the same as pulling the power on a hard disk.
When you write to a USB sector X is not always in the same place. Otherwise frequently written sectors could wear out quickly.
I would hope that the firmware in a USB would be designed to minimize damage, but I don’t know the specifics.
That doesn’t really answer your question though.
On the dinit issue, unless you want two partitions or if you want to boot, having a partition is unnecessary. Just think of the stick as a very large floppy diskette.
I still don’t actually know what’s going on, but I have found a work-around. Thanks to mario’s suggestion, I discovered that mount has a -r option for read-only. This appears to work.
I am nevertheless still annoyed at baffled by the problem.