USB Fun @ QNX4.25

Hi Folks,

long time no see, but i got something freaky once again:

USB-Stick Data Traveller KINGSTON 4GB (One Partition Type 11 (0b) Fat 32)
PC running Windows XP SP3? (NTFS)
Laptop running Mac OSX 10.5.7 (HFS)
Dev-Workstation running QNX4.25 (QNX FS)

One Mail including 2 Image Files:

  • govervr1.jpg
  • govervr.bmp

Created Directory

  • test

So the fun starts, we received this mail from a customer, the two images can be processed, read, written or anything else.
Now we saved them on a USB stick and put them into the Dev-Workstation running QNX4.25.

The files cannot be read.
We renamed them in any way in windows, cannot be read.
We renamed them govervr1xxxxxx1.bmp → can be read on QNX.

WTF part 1

We try it without renaming the file cannot be found. We checked different USB-Sticks, different Workstations anything… nothing works, just in some special naming we get the image.
Errors being shown: No such file or directory.

ls →


Now the best is, we take another file from HD and call it govervr1.jpg and copy it to the USB stick and call another ls:

ls →


WTF part 2

We have two same named files in one partition in one directory on one device? wtf…
Opening the first ends in opening our afterwards-created govervr1.jpg…
So it looks like there is no connection between the directory index and the file itself.

Putting the stick into the windows xp system reveils that you can open the origional govervr1.jpg without any problems. Putting it back into QNX4.25 you cannot access the file anymore…

Now rechecking with OSX you can open the file, read write whatever you want to do with it… Same in windows, just QNX4.25 has some trouble somehow…

We became serious, checked filesystem etc.
THE FILE IS THERE and should be opened but cannot be found.
Now we create a directory on WinXP… taking the stick to QNX4.25 the directory cannot be accessed. It is shown but not accesible. Same as the files before.

We took some long tests now, starting having different namings, filesizes whatever…
There is no logical explenation why the file cannot be read under QNX4.25. More funny is, if we put another file with the SAME NAME on the stick using qnx4.25 we end up in having 2 completly similar named files (same size if we use the same pic, but we took a random one, so different size). In Windows you now also have 2 files having the same name, but just using the second (selfmade) one. In OSX there is just one file with this name and it is the second one.

Going back to where it all began, we saved the image from the mail once more and moved it to the usb stick. Windows can open the file, Linux can oben the file, OSX can open the file, but QNX4.25 shows the file in the listing but any try to open/access the file → No such file or directory

I could go on with hours of testing and having no result at all, but i leave it now to you to decide what the problem is …

Just to tell you, we did not yet solve this
traceinfo did not show anything either…

We reformated the stick, took another one … endless variations and nothing worked for sure…
Somehow some files created on OSX/Windows (or directories) cannot be written in QNX4.25 …

We did check this with the x1 to x3 images also, they had the same trouble when trying to read them from usb. We also tried copying from different machines on the usb stick and …

Funny about this is, you rename it in windows or open and save it another time, it works fine also under QNX4.25. But you have to try a lot to find a name that works – lol –

So somehow we are pretty at a dead end and i hope you enjoy ^^

Are you using Dosfsys or Fatfsys or Fsys.dos? I think Fatfsys is the latest?

We are running Fatfsys. But i found something different, i will check on this now:

ps ax →
Fsys.umass fsys -n Direct-Access=usbmass
Fsys.umass fsys -n Direct-Access=usbmass
Fatfsys -s -L always -V ignore

As you can see we are running 2 instances of io-usb and Fsys.umass, i now wonder if they get autmomatically spawned by our script for every usb-controller or if we have some trouble in our script and it should just run once. Than maybe the source of all this is within the 2 running instances of Fsys.umass and io-usb…