[PATCH] Teach rtems_tarfs_load() about symlinks

[Gedare Bloom]

On Wed, Dec 10, 2014 at 12:36 AM, Nick Withers <nick.withers at anu.edu.au> wrote:
> On Wed, 2014-12-10 at 16:34 +1100, Nick Withers wrote:
>> On Wed, 2014-12-03 at 08:23 +0100, Sebastian Huber wrote:
>> >
>> > On 03/12/14 07:07, Nick Withers wrote:
>> >
>> > > Anyone be interested in committing this?
>> > >
>> > > On Fri, 2014-03-07 at 14:37 +1100, Nick Withers wrote:
>> > > > > Hi all,
>> > > > >
>> > > > > The attached patch teaches rtems_tarfs_load() about symlinks, as well as
>> > > > > making it fail if it encounters an unsupported tar file entry type
>> > > > > (e.g., hard links) rather than silently ignoring the 512 B block.
>> > > > >
>> > > > > It tries to be consistent with the existing code which doesn't e.g.
>> > > > > check tar string field NUL termination or printf() on error.
>> > > -- Nick Withers Embedded Systems Programmer Department of Nuclear
>> > > Physics, Research School of Physics and Engineering The Australian
>> > > National University (CRICOS: 00120C)
>> > >
>> > > rtems_tarfs_load_symlinks.patch
>> > > >From 165b5fd7e0c2d5042a69d209a360522f80697d71 Mon Sep 17 00:00:00 2001
>> > > From: Nick Withers <nick.withers at anu.edu.au>
>> > > Date: Fri, 7 Mar 2014 14:23:30 +1100
>> > > Subject: [PATCH] Teach rtems_tarfs_load() about symlinks
>> > >
>> > > rtems_tarfs_load() will now also fail if it encounters unsupported tar file entry types (e.g., hard links)
>> >
>> > I am not sure if this should now fail if it encounters an unsupported
>> > tar file entry.  This may crash applications that worked for a long
>> > time.
>>
>> Here's a version that doesn't fail like this.
>
> Sorry - I'd left an out-of-date commit message.
>
>> <Discussion>
>> Personally, I'd much rather it did (for example, as I recall, there's
>> nothing to say that an unsupported entry only occupies one block, so you
>> could be stuffed anyway) and would think it would be an obvious failure
>> if you're checking the return code. If you're not, I have no sympathy
>> for you :-P
>>
>> I also think that people porting an existing app to RTEMS 4.11 should be
>> a) not releasing until RTEMS 4.11 itself is finalised OR accepting the
>> potential for breakage working off off the moving HEAD target and b)
>> testing thoroughly.
>>
At this late stage in 4.11 release cycle it is better to be nice to
early adopters. You could suggest turning it into a failure in the
next version of RTEMS.

>> But hey - I don't have to deal with upset users!
>> </Discussion>
>
> --
> Nick Withers
>
> Embedded Systems Programmer
> Department of Nuclear Physics, Research School of Physics and Engineering
> The Australian National University (CRICOS: 00120C)
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel