TFTPS losing current working directory in 4.10

[Chris Johns]

On 19/07/10 5:39 PM, Angus Gratton wrote:
> I've been bringing up EPICS against RTEMS 4.10 and I'm having some
> interesting problems.
>
> For TFTP file access, I've had to make a couple of minor tweaks on the
> client side for changes in the filesystem API. Also two very minor
> tweaks in RTEMS for some corner cases of hostname resolution (will
> provide patches for both lots when I'm done.)
>

Thanks. Please create a single PR with the patches plus a ChangeLog entry.

> However I've now come across something quite weird that seems more
> fundamental. The behaviour I'm seeing is:
>
>
> - EPICS startup sets the cwd to /TFTP/<host>/epics/<client hostname>.
> This value is stored in pathloc->node_access by rtems_tftp_eval_path.
>
> - First file request loads a relative path from the filesystem. This
> works, pathloc->node_access has the cwd and the whole thing resolves
> correctly.
>
> - Second file request is a relative path. At this point, the lookup
> fails. The tftpfs is still consulted but the value in
> pathloc->node_access has changed from the cwd to the string "VERS" and
> the lookup fails (VERS is not a known host.)
>
> - Third file request is a relative path. Also fails, but now because the
> pathloc->node_access value has changed to the empty string.
>
>
> It looks and feels to me like a memory corruption issue, but I'm hoping
> it might ring a bell for someone else before I keep going on.
>
> I've been using RTEMS 4.10 so it is possible this doesn't occur in the
> current CVS. The tftpDriver.c file hasn't changed, but this looks like
> it may be a problem with underlying filesystem layer, or something
> totally unrelated that I'm doing in my code.
>
> If it doesn't ring any bells then I'll put together a simple RTEMS test
> app and try to debug it from there.

A simple test case would be a good idea.

Chris