PR# 2628 Need support for large files (> 2 GB)
Problem Report Summary
Submitter: prestoat2000
Category: EiffelBase
Priority: Medium
Date: 2000/08/22
Class: Support
Severity: Serious
Number: 2628
Release: 4.5.020
Confidential: No
Status: Analyzed
Responsible:
Environment: Mozilla/4.61 [en] (X11; U; SunOS 5.7 sun4u)
Synopsis: Need support for large files (> 2 GB)
Description
In the not too distant future (possibly in as little as 6 months) we will need to be able to read and write large files in an Eiffel application. Large files are files greater than 2 GB. We are in the process of upgrading to Solaris 7, so that the operating system will be able to support large files. We won't have too many of these files at first, but it is very important that we be able to handle them. We would like to find out when ISE Eiffel programs will be able to read and write files greater than 2 GB in size on Solaris. One way to achieve this is to generate 64-bit executables, which can access large files by default. Is it sufficient to have a C compiler than compiles for SPARCV9 or does the Eiffel run-time also have to be compiled with such a C compiler to produce 64-bit executables? (I suspect the latter)
To Reproduce
Problem Report Interactions
Moved to proper category.
Adding interaction for testing.
Will Eiffel ever support files bigger than 2 GB? We have been working around this issue for the last 10 years by maintaining our own set of large file classes. We copied FILE, PLAIN_TEXT_FILE, RAW_FILE, DIRECTORY and UNIX_FILE_INFO and all of their ancestor classes into files named LARGE_FILE, etc. We then changed every INTEGER that might need to be large to INTEGER_64 and also changed a few references to FILE* classes to their LARGE_FILE* counterparts. We also had to copy part of file.c and create "large" routines with new names starting with "large_" to support large files. This works but has several disadvantages: 1. Every time we get a new release, I have to manually compare all of the classes to pick up any changes, including comparison of the C code. This is particularly painful because I have to be careful to keep code that is intentionally different, so that it works correctly for large files. It is also quite time consuming and error-prone. 2. There is of course .... Output truncated, Click download to get the full message
State-Changed-From-To: open-analyzed State-Changed-By: Manu State-Changed-When: Tue Aug 22 11:57:57 PDT 2000 State-Changed-Why: Dear David, For the moment, ie using 4.5, it is not possible. When the next version will be available, we will have a support for INTEGER_64 meaning that you can use the API that is required to access large file. If the API is only available when compiling for SPARCV9, we will also need to do a special port of the run-time. In that case we need access to a Solaris 7 machine which have this option. Let me know if you need more info.