On Wed, Dec 10, 2014 at 12:36 AM, Nick Withers <nick.with...@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.with...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
