[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Testing Large File Support (LFS)

#include <hallo.h>
* Anand Kumria [Tue, Oct 19 2004, 12:53:45AM]:

> I'm just wondering if there is an automated way that we can test programs
> and/or packages to determine if they have working large file support?

I do not think this can be automated easily. Every program has a
different way of working with different files. One thing I can think
about is running whole user sessions in a strace call and evaluate the
strace logs later. Maybe have some modified strace tool that only logs
open calls without O_LARGEFILE, filters open calls on libraries etc.
Once a buggy (LFS-inept) package has been detected, it is added to a
report file and file operations by this programs are to be filtered.

> I've stumbled onto problems in this area, in the past, with Apache and
> Apache2 (fixed upstream but won't be making sarge) and with things like
> wget (no idea about status).

A non-LFS ready wget is a shame. There is wget-cvs which is "recommended
to use". But IMO it is almost ridiculous - we release another Debian
stable without LFS support in important programs, for weak reasons.

> I'm hoping there is some automated tool we can use rather than having to
> find and then report bugs as we go.

The problem is very subtle and not easy to be detected. You cannot even
rely on strings | grep fopen64 or something like that, programs could
implement a part of LFS method but break on some places.

Wer wirklich noch einen 4.x-Browser benutzt, dem kann leider nicht mehr
geholfen werden. Die haben soviele Sicherheitsloecher, da koennten wir per
www.linuxtag.org, Exploit und etwas Scriptmagic einen neuen Browser von
Remote installieren.
                                              // Michael Kleinhenz, lt2k-ml

Reply to: