[Bug 1532] Review Request -- First Test of Loading tarfile info IMFS

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1532





--- Comment #16 from Chris Johns <chrisj at rtems.org>  2010-06-09 23:06:38 ---
>> Yes tar has a range of compatibility issues. This how-ever relates to the
>> implementation in RTEMS and that is not the purpose of this bug.
> Not quite.
>
>
> The patch invokes a host's tar and RTEMS implicitly expects this host's tar to
> produce a specific tar format - This is highly unreliable and non-portable in
> general.

Given a specific tar we can have RTEMS support it. If this is not true then the
tar code in RTEMS becomes questionable.

Should the tar code be migrated to support pax instead ? It supports the ustar
Interchange Format.

> Furthermore, in the latest version of the patch contains this:
>  tar cf - --exclude-vcs home symlink && rm -f symlink
> where its predecessor had contained this:
>  tar cf - home symlink && rm -f symlink
>
> This is a regression of "the new version" over the "old version". 

Yes this makes the test specific to a version of tar. Who cares if CVS or
whatever ends up in the target. I suspect a small memory target would not be
running this test anyway.

>> ... can we construct an autoconf test for a specific version of tar
>> we know is compatible with the implementation in RTEMS ?
> It's a can of worms, IMO.
>
> 1. The "RTEMS tar format" would have to be "clearly specified" (ustar, 7bit
> ASCII, case-sensitivity of the hosting OS/build OS (recently there have been
> reports on OS X being case insenistive!!!!), file permissions (consider umask))
> ...

Agreed. On MacOS that may not be tar's fault :)

 $ touch A
 $ mkdir a
 mkdir: a: File exists

> 2. The details of the "RTEMS tar loader" would have to be clearly specified.
> What does the RTEMS tar loader need and what does it ignore?

I see pax is formally documented.

>3. Which cmd-line options does which tar implementation need to produce a tar
> ball to meet 1. + 2.
> Note: A tar-implementation defaults may change over time, as well as individual
> tar implementation might temporarily be broken (Both has happened in gtar's
history)
>
> That said, ATM, I only see one possibility: provide a sample tarball as part of
> an autoconf check and let this autoconf check try to reproduce this sample
> using an ultra conservative set of tar command-line options (tar [xc]f -) +
> locales set to C).

See pax above.

> If this fails, fall back to disabling this test.

Agreed.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.