[PATCH] Teach rtems_tarfs_load() about symlinks

Nick Withers nick.withers at anu.edu.au
Wed Dec 10 05:36:53 UTC 2014


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.
> 
> 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems_tarfs_load_symlinks.patch
Type: text/x-patch
Size: 3024 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141210/2594f8e2/attachment.bin>


More information about the devel mailing list