[RTEMS Project] #2190: an external fat16 image does not work properly, getcwd() fails

[RTEMS trac]

#2190: an external fat16 image does not work properly, getcwd() fails
--------------------------+---------------------
 Reporter:  marco.hoefle  |       Owner:  chrisj
     Type:  defect        |      Status:  new
 Priority:  low           |   Milestone:  5.0
Component:  filesystem    |     Version:  4.11
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+---------------------
Changes (by sebastian.huber):

 * priority:  normal => low
 * milestone:  4.11 => 5.0


Old description:

> 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.

New description:

 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.

--

--
Ticket URL: <http://devel.rtems.org/ticket/2190#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project