From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne?

> >>> Interesting test philosophy you have there. Some people would wait
> >>> until _after_ they've tried it before becoming "definitively sure" about
> >>> it. Compiling with _LARGEFILE defined does not ensure the use of 64-bit
> >> I know that Python on VMS correctly handle large file because it pass
> >> all the tests provide to check that large file support is present.

> >
> > Do any of those tests involve a file bigger than 2GB? 8GB? As I
> > said, "interesting".
> >
> >> I don't remember having mentionned that "compiling with _LARGEFILE" is
> >> what I have test.


> > [Explanation of the equivalence of the this with what you did claim
> > omitted here.]


> > True. You didn't actually provide much of a description of your
> > tests.

>
> So as I don't provide a description you assume I haven't done any test,
> interesting.


No, what I assume is that you've run some simple-minded test which
ensures that file-size/offset variables are 8 bytes, not four. What I
assume that you haven't run is a useful, more realistic test which
involves actual large files in a large "tar" archive. But feel free to
tell me that you really _did_ run some serious "tar" tests.

> For the third time, I *have* run all the tests to check that the 64 bits
> support is correct. So until you prove the opposite it work.
> Y have done a assumption about something I haven't written, so read
> carefully:
> All the 64 bits file support tests without any problem.


And, for the Nth time (where I've lost track of N), that is not
certain to be a useful test of "tar" capability on large files, which is
what I thought that we were discussing, any more than it would have been
a useful test of UnZip+Zip capability on large files, because there's
more involved in such support than use of large file size/offset
variables.

> As this thread seem, now, sterile, this is my last post.


Well, that's a mercy.

SMS.