[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Fwd: Re: 64 bit file support
From:       Hetz Ben Hamo <hetz () kde ! org>
Date:       2001-08-10 19:39:03
[Download RAW message or body]

Do u want me to talk to the Compaq test drive web site admin to give us 
couple of shells on their Alpha's to do some testings??

Hetz

On Friday 10 August 2001 21:53, Waldo Bastian wrote:
> Hiya,
>
> One of the things todo for KDE 3.0 is to get 64-bit file support working.
> You might want to read the following URL in order to understand the
> problem.
>
> http://ftp.sas.com/standards/large.file/x_open.20Mar96.html
>
> It seems that since we can't control the way in which either Qt, other libs
> or applications are being compiled we will need to use the "Transitional
> Extensions".
>
> I haven't tried it yet but I hope that we can circumvent this define mess
> that Jeff talks about. I'm sure that after all the problems with X-headers
> the glibc-developers wouldn't be that stupid.
>
> As far as KDE's internal interfaces goes, I think that we should start to
> use "long long" in the interfaces that need it. Maybe we can add a
> KIO::filesize_t typedef so that we have a central place to change it to
> something else.
>
> Cheers,
> Waldo
>
> ----------  Forwarded Message  ----------
>
> Subject: Re: 64 bit file support
> Date: Mon, 6 Aug 2001 14:53:46 -0400
> From: Jeff Woods <Jeff.Woods@ChoicePointPRG.net>
> To: Waldo Bastian <bastian@kde.org>
>
> On Wednesday 25 July 2001 02:56 pm, you wrote:
> > There are various problems with 64 bit file-sizes, one of them being that
> > our APIs don't support 64 bits. We hope to fix that in KDE 3.0. Your
> > experiences will be usefull in that regard so that we know what needs
> > fixing.
>
> We finally got 64 files partially supported.  Basically, we replaced the
> stat's and lstat's in kio/kfileitem.cpp and kio/file/file.cc with stat64
> and lstat64.  This allows files with sizes greater than 4 GB to be
> displayed in the file browser (which was our greatest concern).  The
> application we've been working with already used 64 bit access routines
> where necessary.
>
> This solution won't work under Linux, though.  Linux headers define "struct
> stat" based on the value of _FILE_OFFSET_BITS.  If you place the line
> "#define _FILE_OFFSET_BITS 64" prior to any #include's in your source, you
> get the 64 bit version, otherwise you get the 32 bit version.  An
> unfortunate side effect of this is that all system calls, such as open and
> truncate,  get a #define like this:
>
> #define open open64
> #define truncate truncate64
>
> This caused problems with some QT member functions which had the same name
> as a system call.  For example, QString::truncate() was renamed
> QString::truncate64(), which did not resolve against the QT dynamic
> library.
>
> We were able to get away with this since Solaris defines a seperate "struct
> stat64" for use with stat64 and lstat64.  We just surrounded our changes
> with #ifdef sun ... #endif statements to keep the builds clean.
>
> As you're aware, there are many more changes which are necessary.  Even
> though we are able to list the file, we do not get the correct file size.
> This would require a number of internal changes.
>
> I've attached the changed files (my reason for not posting to the developer
> list).
>
> Jeff Woods
>
> -------------------------------------------------------

-- 
Hetz Ben Hamo
hetz@kde.org

[prev in list] [next in list] [prev in thread] [next in thread]