an external fat16 image does not work properly, getcwd() fails

[Marco]

getcwd() syscall fails when browsing deeper in the mounted filesystem.
A wrong path is returned (also in rtems4.10 which is our target platform)

Discussion was on mailing list:
​http://lists.rtems.org/pipermail/users/2014-October/028297.html

Test case:
an external fat16 image is created with a default content using the following tools:
dd
mkfs.vfat
mcopy
xxd

the mkfs generated image is converted to a C data array and compiled to an object file.
This object file is then linked into the rtems application.

Steps to compile the test case:
The above tools need to be installed on a Linx build machine (debian wheezy used here)

The top level Makefile in the src folder expects the sparc rtems 4.11 toolchain in the $(project_root_dir)/build/toolchain/

Toolchain is not attached as it is very big. But if desired I can provide a link to download it.

The top level Makefile calls the fatfs image generation Makefile and then the application Makefile.

The test case app sets up two ramdisks.
One under /sdram -> this one id formated using rtems dosfs functions
and one under /mram -> this should contain the default content

then a dummy thread and the rtems shell is started.

We suppose it is getcwd() as we had this behaviour in our final application using this system call.

If something is missing or so please contact me.

[Marco]

test project

[Marco]

ok
I will create one in addition to the attached test case. It will be a Makefile approach and also a native linux app demonstrating that the fatfs image is ok.
It will take me a week or two.

[Sebastian Huber]

We fixed a couple of FAT bugs. Maybe it works now.