Re: [boost] [filesystem] On POSIX, any reliable way to find file size?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-01-31 17:36:58

At 12:44 PM 1/31/2004, Jens Maurer wrote:
 >
 >Beman Dawes wrote:
 >> On POSIX compliant 32-bit systems, is there any reliable way to find 
the
 >> size of a file?
 >
 >First, POSIX only had stat(), which is limited to 32 bits, as you
 >found out.  When files got large enough that this wasn't a good
 >assumption any more even on 32bit systems, a new interface was
 >introduced:  stat64() which has, for example, a 64bit
 >stat64::st_size .
 >(Btw, Linux 2.6 supports up to 16 TB file sizes on 32bit machines,
 >AFAIK.)
 >
 >Of course, 64bit environments have their regular stat()
 >use 64bit stat::st_size.
 >
 >You get stat64() by #define _LARGEFILE64_SOURCE .
 >You get stat() to use a 64bit stat::st_size even on 32bit
 >environments by #define _FILE_OFFSET_BITS=64 .

So it sounds like Boost.Filesystem could have an implementation-defined 
type, say "file_offset_type", which would be either long or long long. Then 
Boost.Filesystem would provide:

    file_offset_type size( const path & );

The implementation would go something like this:

    #if defined( BOOST_WINDOWS )
       // use the Windows native API; file_offset_type is long long.
       ...
    #else
       #define _FILE_OFFSET_BITS 64 // this may or may not do anything
       // use stat(); file_offset_type is same as off_t,
       // which may be 32-bits on 32-bit platforms which don't
       // respond to _FILE_OFFSET_BITS
       ...
    #endif

Does that make sense? It will take some configuration work to know whether 
to typedef file_offset_type to long or long long; we don't want to expose 
platform header files in the Boost header. Need to think about that.

 >Both options require reasonably recent Unix systems.
 >The latter option may impede binary compatibility if some
 >modules are compiled with the #define and others aren't,
 >because the perceived "struct stat" size will be different.

If the use of "struct stat" is hidden within a Boost.Filesystem 
implementation file, will that be a problem? I wouldn't think so.

Thanks,

--Beman