readelf: use fseeko for elf files >= 2 GiB on x86_64-mingw32
Checks
Commit Message
Switch all fseek calls to fseeko and cast the given offset as an off_t
accordingly. When building readelf for x86_64-mingw32, a long will only
be 32 bits wide. If the elf file in question is >= 2 GiB, that is
greater than the max long value, and therefore fseek will fail
indicating that the offset is negative.
To work around this and support up to 4 GiB, we switch to using fseeko
and cast the unsigned long offsets as off_t values because the size of
off_t is 64 bits on x86_64-mingw32.
---
binutils/readelf.c | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
Comments
On 14.11.2022 16:03, Brett Werling via Binutils wrote:
> Switch all fseek calls to fseeko and cast the given offset as an off_t
> accordingly. When building readelf for x86_64-mingw32, a long will only
> be 32 bits wide. If the elf file in question is >= 2 GiB, that is
> greater than the max long value, and therefore fseek will fail
> indicating that the offset is negative.
>
> To work around this and support up to 4 GiB, we switch to using fseeko
> and cast the unsigned long offsets as off_t values because the size of
> off_t is 64 bits on x86_64-mingw32.
Is fseeko() uniformly available on all platforms binutils can be built
for? I'm afraid the answer is no, so at least you'd need to introduce
some configure logic for this plus some abstraction.
Jan
On Mon, Nov 14, 2022 at 9:30 AM Jan Beulich <jbeulich@suse.com> wrote:
> On 14.11.2022 16:03, Brett Werling via Binutils wrote:
> > Switch all fseek calls to fseeko and cast the given offset as an off_t
> > accordingly. When building readelf for x86_64-mingw32, a long will only
> > be 32 bits wide. If the elf file in question is >= 2 GiB, that is
> > greater than the max long value, and therefore fseek will fail
> > indicating that the offset is negative.
> >
> > To work around this and support up to 4 GiB, we switch to using fseeko
> > and cast the unsigned long offsets as off_t values because the size of
> > off_t is 64 bits on x86_64-mingw32.
>
> Is fseeko() uniformly available on all platforms binutils can be built
> for? I'm afraid the answer is no, so at least you'd need to introduce
> some configure logic for this plus some abstraction.
>
> Jan
>
I think you are correct, this will need some conditional logic to be "safe"
to
include, and even then the casting to off_t would become a little more
complicated. I will look deeper into what can be done here.
I had also considered iterative calls on fseek() using longs and SEEK_CUR,
just ensuring that we don't blow past LONG_MAX. That didn't seem as
clean or efficient of a change, so I dropped it.
Brett
On Mon, Nov 14, 2022 at 09:52:30AM -0600, Brett Werling via Binutils wrote:
> On Mon, Nov 14, 2022 at 9:30 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> > On 14.11.2022 16:03, Brett Werling via Binutils wrote:
> > > Switch all fseek calls to fseeko and cast the given offset as an off_t
> > > accordingly. When building readelf for x86_64-mingw32, a long will only
> > > be 32 bits wide. If the elf file in question is >= 2 GiB, that is
> > > greater than the max long value, and therefore fseek will fail
> > > indicating that the offset is negative.
> > >
> > > To work around this and support up to 4 GiB, we switch to using fseeko
> > > and cast the unsigned long offsets as off_t values because the size of
> > > off_t is 64 bits on x86_64-mingw32.
> >
> > Is fseeko() uniformly available on all platforms binutils can be built
> > for? I'm afraid the answer is no, so at least you'd need to introduce
> > some configure logic for this plus some abstraction.
> >
> > Jan
> >
>
> I think you are correct, this will need some conditional logic to be "safe"
> to
> include, and even then the casting to off_t would become a little more
> complicated. I will look deeper into what can be done here.
See bfd/bfdio.c and bfd/configure.ac
> I had also considered iterative calls on fseek() using longs and SEEK_CUR,
> just ensuring that we don't blow past LONG_MAX. That didn't seem as
> clean or efficient of a change, so I dropped it.
>
> Brett
On 15 Nov 2022 08:12, Alan Modra via Binutils wrote:
> On Mon, Nov 14, 2022 at 09:52:30AM -0600, Brett Werling via Binutils wrote:
> > On Mon, Nov 14, 2022 at 9:30 AM Jan Beulich <jbeulich@suse.com> wrote:
> > > On 14.11.2022 16:03, Brett Werling via Binutils wrote:
> > > > Switch all fseek calls to fseeko and cast the given offset as an off_t
> > > > accordingly. When building readelf for x86_64-mingw32, a long will only
> > > > be 32 bits wide. If the elf file in question is >= 2 GiB, that is
> > > > greater than the max long value, and therefore fseek will fail
> > > > indicating that the offset is negative.
> > > >
> > > > To work around this and support up to 4 GiB, we switch to using fseeko
> > > > and cast the unsigned long offsets as off_t values because the size of
> > > > off_t is 64 bits on x86_64-mingw32.
> > >
> > > Is fseeko() uniformly available on all platforms binutils can be built
> > > for? I'm afraid the answer is no, so at least you'd need to introduce
> > > some configure logic for this plus some abstraction.
> >
> > I think you are correct, this will need some conditional logic to be "safe"
> > to
> > include, and even then the casting to off_t would become a little more
> > complicated. I will look deeper into what can be done here.
>
> See bfd/bfdio.c and bfd/configure.ac
should we look at bfd using gnulib ? growing our own portability layer sounds
like a lot of dupicative effort ...
at the very least, binutils/ should be able to without much trouble.
-mike
On 16.11.2022 11:09, Mike Frysinger wrote:
> On 15 Nov 2022 08:12, Alan Modra via Binutils wrote:
>> On Mon, Nov 14, 2022 at 09:52:30AM -0600, Brett Werling via Binutils wrote:
>>> On Mon, Nov 14, 2022 at 9:30 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 14.11.2022 16:03, Brett Werling via Binutils wrote:
>>>>> Switch all fseek calls to fseeko and cast the given offset as an off_t
>>>>> accordingly. When building readelf for x86_64-mingw32, a long will only
>>>>> be 32 bits wide. If the elf file in question is >= 2 GiB, that is
>>>>> greater than the max long value, and therefore fseek will fail
>>>>> indicating that the offset is negative.
>>>>>
>>>>> To work around this and support up to 4 GiB, we switch to using fseeko
>>>>> and cast the unsigned long offsets as off_t values because the size of
>>>>> off_t is 64 bits on x86_64-mingw32.
>>>>
>>>> Is fseeko() uniformly available on all platforms binutils can be built
>>>> for? I'm afraid the answer is no, so at least you'd need to introduce
>>>> some configure logic for this plus some abstraction.
>>>
>>> I think you are correct, this will need some conditional logic to be "safe"
>>> to
>>> include, and even then the casting to off_t would become a little more
>>> complicated. I will look deeper into what can be done here.
>>
>> See bfd/bfdio.c and bfd/configure.ac
>
> should we look at bfd using gnulib ? growing our own portability layer sounds
> like a lot of dupicative effort ...
Right now binutils can be built and run on pretty old distros. Unless a pretty
old gnulib would be taken as the baseline, this property would be lost with
the introduction of such a dependency.
Jan
On 16 Nov 2022 11:46, Jan Beulich wrote:
> On 16.11.2022 11:09, Mike Frysinger wrote:
> > On 15 Nov 2022 08:12, Alan Modra via Binutils wrote:
> >> On Mon, Nov 14, 2022 at 09:52:30AM -0600, Brett Werling via Binutils wrote:
> >>> On Mon, Nov 14, 2022 at 9:30 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>> On 14.11.2022 16:03, Brett Werling via Binutils wrote:
> >>>>> Switch all fseek calls to fseeko and cast the given offset as an off_t
> >>>>> accordingly. When building readelf for x86_64-mingw32, a long will only
> >>>>> be 32 bits wide. If the elf file in question is >= 2 GiB, that is
> >>>>> greater than the max long value, and therefore fseek will fail
> >>>>> indicating that the offset is negative.
> >>>>>
> >>>>> To work around this and support up to 4 GiB, we switch to using fseeko
> >>>>> and cast the unsigned long offsets as off_t values because the size of
> >>>>> off_t is 64 bits on x86_64-mingw32.
> >>>>
> >>>> Is fseeko() uniformly available on all platforms binutils can be built
> >>>> for? I'm afraid the answer is no, so at least you'd need to introduce
> >>>> some configure logic for this plus some abstraction.
> >>>
> >>> I think you are correct, this will need some conditional logic to be "safe"
> >>> to
> >>> include, and even then the casting to off_t would become a little more
> >>> complicated. I will look deeper into what can be done here.
> >>
> >> See bfd/bfdio.c and bfd/configure.ac
> >
> > should we look at bfd using gnulib ? growing our own portability layer sounds
> > like a lot of dupicative effort ...
>
> Right now binutils can be built and run on pretty old distros. Unless a pretty
> old gnulib would be taken as the baseline, this property would be lost with
> the introduction of such a dependency.
sounds like an issue to bring up with the gnulib folks then ?
it's already a hard requirement for gdb and related.
realistically, is anyone actually testing those old distros ?
-mike
Hello,
On Wed, 16 Nov 2022, Mike Frysinger via Binutils wrote:
> > >>> I think you are correct, this will need some conditional logic to be "safe"
> > >>> to
> > >>> include, and even then the casting to off_t would become a little more
> > >>> complicated. I will look deeper into what can be done here.
> > >>
> > >> See bfd/bfdio.c and bfd/configure.ac
> > >
> > > should we look at bfd using gnulib ?
The patch is for readelf, which doesn't use libbfd. (And if readelf
should use gnulib for this? I don't know, seems overkill for a single
function).
> > > growing our own portability layer sounds
> > > like a lot of dupicative effort ...
I think "growing" and "lot of" don't describe the effort. Rewriting to
use gnulib (and the corresponding necessary testing) might be trivial as
well (though I don't think so), but the returns are still very small.
> realistically, is anyone actually testing those old distros ?
Depends on the definition of old. For instance our oldish enterprise
stuff (SLES12) still has current binutils, so at least there it's tested
relatively good. OTOH it's only 9 years old, so some might say that
doesn't qualify :)
Ciao,
Michael.
On 16 Nov 2022 14:44, Michael Matz wrote:
> On Wed, 16 Nov 2022, Mike Frysinger via Binutils wrote:
> > > >>> I think you are correct, this will need some conditional logic to be "safe"
> > > >>> to
> > > >>> include, and even then the casting to off_t would become a little more
> > > >>> complicated. I will look deeper into what can be done here.
> > > >>
> > > >> See bfd/bfdio.c and bfd/configure.ac
> > > >
> > > > should we look at bfd using gnulib ?
>
> The patch is for readelf, which doesn't use libbfd.
i'm aware. my original message called this difference out. using gnulib
in libbfd seems dicey when statically linking is common, and gnulib does
not provide symbol isolation, which means we'd see a lot of bleeding.
> (And if readelf
> should use gnulib for this? I don't know, seems overkill for a single
> function).
>
> > > > growing our own portability layer sounds
> > > > like a lot of dupicative effort ...
>
> I think "growing" and "lot of" don't describe the effort. Rewriting to
> use gnulib (and the corresponding necessary testing) might be trivial as
> well (though I don't think so), but the returns are still very small.
i disagree with your assessment. the patch proposed isn't exactly trivial,
nor is it widely tested like gnulib.
further, if you read the existing binutils/configure.ac, there's a lot of
"copied from gnulib" logic in there that would get cleaned up. there's
also logic for old systems that i doubt aren't actively tested (e.g. who
is actually building on Next 3.2?).
even further, readelf isn't the only file under binutils/ that uses fseek,
but it seems to be the only program you're trying to fix. so the others
are still broken, which wouldn't be the case if gnulib was used.
even even further, gnulib is already in the tree. it isn't like you have
to import & integrate its build logic or manage its autotool logic or its
header paths. there are 3 top-level projects using it now, one of which
i converted, and it was pretty trivial.
> > realistically, is anyone actually testing those old distros ?
>
> Depends on the definition of old. For instance our oldish enterprise
> stuff (SLES12) still has current binutils, so at least there it's tested
> relatively good. OTOH it's only 9 years old, so some might say that
> doesn't qualify :)
assuming it shipped with a glibc version that supported POSIX 1003.1 (2013
edition), no, i don't consider that to be that old. it's got all the fun
*at APIs and such. i don't recall what the 2016 edition introduced, and i
don't think there are easy summaries to find, but i doubt much of it would
be relevant for binutils/.
are you claiming that current gnulib versions can't support even those old
versions of glibc ? i'd find that extremely surprising, and really sounds
like a bug that should be taken up with the gnulib folks.
-mike
> [... snip ...]
>> I think "growing" and "lot of" don't describe the effort. Rewriting to
>> use gnulib (and the corresponding necessary testing) might be trivial as
>> well (though I don't think so), but the returns are still very small.
>
> i disagree with your assessment. the patch proposed isn't exactly trivial,
> nor is it widely tested like gnulib.
>
> further, if you read the existing binutils/configure.ac, there's a lot of
> "copied from gnulib" logic in there that would get cleaned up. there's
> also logic for old systems that i doubt aren't actively tested (e.g. who
> is actually building on Next 3.2?).
>
> even further, readelf isn't the only file under binutils/ that uses fseek,
> but it seems to be the only program you're trying to fix. so the others
> are still broken, which wouldn't be the case if gnulib was used.
>
> even even further, gnulib is already in the tree. it isn't like you have
> to import & integrate its build logic or manage its autotool logic or its
> header paths. there are 3 top-level projects using it now, one of which
> i converted, and it was pretty trivial.
FWIW, we are considering making BFD to import a gnulib module with the
sframe encoders and decoders (we already submitted the new module to
bug-gnulib and it is under review) rather than having to maintain a
separated libsframe in the tree.
I also agree with Mike in that using gnulib in bfd would bring many
other advantages...
Hello,
On Wed, 16 Nov 2022, Mike Frysinger wrote:
> are you claiming that current gnulib versions can't support even those old
> versions of glibc ? i'd find that extremely surprising, and really sounds
> like a bug that should be taken up with the gnulib folks.
No. I'm claiming that moving to gnulib is work (even if perhaps not
much?) and change and I (personally) don't see the need to invest into
that work and deal with the change. Had you asked "should I look into
using gnulib in bfd" my answer would have been "well, try it, why not?".
But you asked "should _we_ look" (aka should someone do that), hence my
answer was in the line of "perhaps, but why bother?".
So, I'm not at all doubting that gnulib would be fit for the purpose, it
most likely is. It just seems (to me!) like a solution in search for a
problem.
Ciao,
Michael.
On 16 Nov 2022 16:13, Michael Matz wrote:
> On Wed, 16 Nov 2022, Mike Frysinger wrote:
> > are you claiming that current gnulib versions can't support even those old
> > versions of glibc ? i'd find that extremely surprising, and really sounds
> > like a bug that should be taken up with the gnulib folks.
>
> No. I'm claiming that moving to gnulib is work (even if perhaps not
> much?) and change and I (personally) don't see the need to invest into
> that work and deal with the change. Had you asked "should I look into
> using gnulib in bfd" my answer would have been "well, try it, why not?".
> But you asked "should _we_ look" (aka should someone do that), hence my
> answer was in the line of "perhaps, but why bother?".
you're proposing adding a not insignificant amount of custom portability logic
and making the readelf code harder to understand & maintain while also not
fixing the same bug in other binutils/ tools. it is perfectly reasonable to
ask you to not add tech debt & make the code base worse off for everyone else
to maintain, and instead focus on a common solution that the GNU project is
already heavily invested in. this is, of course, the "GNU Binutils" project.
-mike
On Wed, Nov 16, 2022 at 11:09 AM Mike Frysinger <vapier@gentoo.org> wrote:
>
> On 16 Nov 2022 16:13, Michael Matz wrote:
> > On Wed, 16 Nov 2022, Mike Frysinger wrote:
> > > are you claiming that current gnulib versions can't support even those old
> > > versions of glibc ? i'd find that extremely surprising, and really sounds
> > > like a bug that should be taken up with the gnulib folks.
> >
> > No. I'm claiming that moving to gnulib is work (even if perhaps not
> > much?) and change and I (personally) don't see the need to invest into
> > that work and deal with the change. Had you asked "should I look into
> > using gnulib in bfd" my answer would have been "well, try it, why not?".
> > But you asked "should _we_ look" (aka should someone do that), hence my
> > answer was in the line of "perhaps, but why bother?".
>
> you're proposing adding a not insignificant amount of custom portability logic
> and making the readelf code harder to understand & maintain while also not
> fixing the same bug in other binutils/ tools. it is perfectly reasonable to
> ask you to not add tech debt & make the code base worse off for everyone else
> to maintain, and instead focus on a common solution that the GNU project is
> already heavily invested in. this is, of course, the "GNU Binutils" project.
> -mike
I must admit, I'm quite unfamiliar with the history here and my
original intention
was to just provide a solution to a specific issue I found with
readelf. Anything
beyond that is probably outside the scope of what I'm comfortable addressing.
If someone else wants to take what I've started here and drive it to completion
as part of a larger effort, please feel free!
Also wanted to make sure that my second patch was seen? I think it addresses
the original concern raised by Jan, but perhaps more is still needed there.
Brett
On 16 Nov 2022 15:19, Brett Werling via Binutils wrote:
> On Wed, Nov 16, 2022 at 11:09 AM Mike Frysinger wrote:
> > On 16 Nov 2022 16:13, Michael Matz wrote:
> > > On Wed, 16 Nov 2022, Mike Frysinger wrote:
> > > > are you claiming that current gnulib versions can't support even those old
> > > > versions of glibc ? i'd find that extremely surprising, and really sounds
> > > > like a bug that should be taken up with the gnulib folks.
> > >
> > > No. I'm claiming that moving to gnulib is work (even if perhaps not
> > > much?) and change and I (personally) don't see the need to invest into
> > > that work and deal with the change. Had you asked "should I look into
> > > using gnulib in bfd" my answer would have been "well, try it, why not?".
> > > But you asked "should _we_ look" (aka should someone do that), hence my
> > > answer was in the line of "perhaps, but why bother?".
> >
> > you're proposing adding a not insignificant amount of custom portability logic
> > and making the readelf code harder to understand & maintain while also not
> > fixing the same bug in other binutils/ tools. it is perfectly reasonable to
> > ask you to not add tech debt & make the code base worse off for everyone else
> > to maintain, and instead focus on a common solution that the GNU project is
> > already heavily invested in. this is, of course, the "GNU Binutils" project.
>
> I must admit, I'm quite unfamiliar with the history here and my
> original intention
> was to just provide a solution to a specific issue I found with
> readelf. Anything
> beyond that is probably outside the scope of what I'm comfortable addressing.
> If someone else wants to take what I've started here and drive it to completion
> as part of a larger effort, please feel free!
>
> Also wanted to make sure that my second patch was seen? I think it addresses
> the original concern raised by Jan, but perhaps more is still needed there.
the 2nd patch is what prompted me to follow up to the thread ;). i grok that
it addresses the specific issue you've found, but it isn't a complete fix, nor
one that improves the codebase for the maintainers to maintain long term.
-mike
Hello,
On Thu, 17 Nov 2022, Mike Frysinger wrote:
> > No. I'm claiming that moving to gnulib is work (even if perhaps not
> > much?) and change and I (personally) don't see the need to invest into
> > that work and deal with the change. Had you asked "should I look into
> > using gnulib in bfd" my answer would have been "well, try it, why not?".
> > But you asked "should _we_ look" (aka should someone do that), hence my
> > answer was in the line of "perhaps, but why bother?".
>
> you're proposing adding a not insignificant amount of custom portability
> logic
I'm not proposing anything, but I guess I consider the amount of
portability code to be actually insignificant in this case.
> and making the readelf code harder to understand & maintain while
> also not fixing the same bug in other binutils/ tools. it is perfectly
> reasonable to ask you to not add tech debt & make the code base worse
> off for everyone else to maintain, and instead focus on a common
> solution that the GNU project is already heavily invested in. this is,
> of course, the "GNU Binutils" project.
Yeah, well, until someone does the work I guess we'll never know.
Ciao,
Michael.
@@ -424,7 +424,7 @@ get_data (void * var,
return NULL;
}
- if (fseek (filedata->handle, archive_file_offset + offset, SEEK_SET))
+ if (fseeko (filedata->handle, (off_t)archive_file_offset + offset, SEEK_SET))
{
if (reason)
error (_("Unable to seek to 0x%lx for %s\n"),
@@ -5343,7 +5343,7 @@ process_program_headers (Filedata * filedata)
break;
case PT_INTERP:
- if (fseek (filedata->handle, archive_file_offset + (long) segment->p_offset,
+ if (fseeko (filedata->handle, (off_t)archive_file_offset + (long) segment->p_offset,
SEEK_SET))
error (_("Unable to find program interpreter name\n"));
else
@@ -11720,8 +11720,8 @@ process_symbol_table (Filedata * filedata)
&& filedata->file_header.e_ident[EI_CLASS] == ELFCLASS64)
hash_ent_size = 8;
- if (fseek (filedata->handle,
- (archive_file_offset
+ if (fseeko (filedata->handle,
+ ((off_t)archive_file_offset
+ offset_from_vma (filedata, dynamic_info[DT_HASH],
sizeof nb + sizeof nc)),
SEEK_SET))
@@ -11772,8 +11772,8 @@ process_symbol_table (Filedata * filedata)
bfd_vma i, maxchain = 0xffffffff, bitmaskwords;
bfd_vma buckets_vma;
- if (fseek (filedata->handle,
- (archive_file_offset
+ if (fseeko (filedata->handle,
+ ((off_t)archive_file_offset
+ offset_from_vma (filedata, dynamic_info_DT_GNU_HASH,
sizeof nb)),
SEEK_SET))
@@ -11797,8 +11797,8 @@ process_symbol_table (Filedata * filedata)
else
buckets_vma += bitmaskwords * 8;
- if (fseek (filedata->handle,
- (archive_file_offset
+ if (fseeko (filedata->handle,
+ ((off_t)archive_file_offset
+ offset_from_vma (filedata, buckets_vma, 4)),
SEEK_SET))
{
@@ -11826,8 +11826,8 @@ process_symbol_table (Filedata * filedata)
maxchain -= gnusymidx;
- if (fseek (filedata->handle,
- (archive_file_offset
+ if (fseeko (filedata->handle,
+ ((off_t)archive_file_offset
+ offset_from_vma (filedata, buckets_vma
+ 4 * (ngnubuckets + maxchain), 4)),
SEEK_SET))
@@ -11851,8 +11851,8 @@ process_symbol_table (Filedata * filedata)
}
while ((byte_get (nb, 4) & 1) == 0);
- if (fseek (filedata->handle,
- (archive_file_offset
+ if (fseeko (filedata->handle,
+ ((off_t)archive_file_offset
+ offset_from_vma (filedata, buckets_vma + 4 * ngnubuckets, 4)),
SEEK_SET))
{
@@ -11868,8 +11868,8 @@ process_symbol_table (Filedata * filedata)
if (dynamic_info_DT_MIPS_XHASH)
{
- if (fseek (filedata->handle,
- (archive_file_offset
+ if (fseeko (filedata->handle,
+ ((off_t)archive_file_offset
+ offset_from_vma (filedata, (buckets_vma
+ 4 * (ngnubuckets
+ maxchain)), 4)),
@@ -20185,7 +20185,7 @@ process_archive (Filedata * filedata, bfd_boolean is_thin_archive)
ret = FALSE;
}
- if (fseek (filedata->handle, current_pos, SEEK_SET) != 0)
+ if (fseeko (filedata->handle, (off_t)current_pos, SEEK_SET) != 0)
{
error (_("%s: failed to seek back to start of object files in the archive\n"),
filedata->file_name);
@@ -20211,7 +20211,7 @@ process_archive (Filedata * filedata, bfd_boolean is_thin_archive)
char * qualified_name;
/* Read the next archive header. */
- if (fseek (filedata->handle, arch.next_arhdr_offset, SEEK_SET) != 0)
+ if (fseeko (filedata->handle, (off_t)arch.next_arhdr_offset, SEEK_SET) != 0)
{
error (_("%s: failed to seek to next archive header\n"), arch.file_name);
return FALSE;
@@ -20309,7 +20309,7 @@ process_archive (Filedata * filedata, bfd_boolean is_thin_archive)
/* The nested archive file will have been opened and setup by
get_archive_member_name. */
- if (fseek (nested_arch.file, archive_file_offset, SEEK_SET) != 0)
+ if (fseeko (nested_arch.file, (off_t)archive_file_offset, SEEK_SET) != 0)
{
error (_("%s: failed to seek to archive member.\n"), nested_arch.file_name);
ret = FALSE;