From: Carsten Hoeger (no email)
Date: Mon Sep 01 2003 - 14:18:43 EDT
On Mon, Sep 01, Wietse Venema wrote:
> > sorry, that I have to start that thread again, but I got a bugreport of a user
> > insisting on sending attachments with a size > 2GB on his 64bit machine.
> > So I just had a look at the code and found, that e.g. in master/master.c
> > there's:
> >
> > if ((inherited_limit = get_file_limit()) < (off_t) INT_MAX)
> > set_file_limit(INT_MAX);
> >
> > INT_MAX is always 4 bytes long, so it doesn't care on which platform I run
> > postfix, I'll always get a max of 2147483648 bytes per file.
> >
> > So why not use the max size off off_t, e.g. using this code:
> >
> > #define FSIZE_MAX (off_t)1<<((sizeof(off_t)*8)-1)
> >
> > to determine the maximum size of a file?
>
> How portable is this? The standard says nothing about the representation
> of an off_t, and Postfix makes no assumptions about it. For all we
> know it could be packed decimal (BCD) or roman numerals.
Well... no comment on this one.
Why do you fall back to INT_MAX?
> > in util/file_limit.c
> >
> > off_t get_file_limit(void)
> > {
> > off_t limit;
> >
> > [...] ifdef ULIMIT stuff removed
> >
> > struct rlimit rlim;
> >
> > if (getrlimit(RLIMIT_FSIZE, &rlim) < 0)
> > msg_fatal("getrlimit: %m");
> > limit = rlim.rlim_cur;
> > return (limit < 0 ? INT_MAX : rlim.rlim_cur);
> > }
> >
> > What is this test for?
>
> This is pampering for brain-dead Linux boxes that returned an
> unsigned 4GB value into a signed integer, resulting in a negative
> file size result.
I've been told, that
... getrlimit(RLIMIT_FSIZE, &rlim) returns ULONG_MAX, the
limit the kernel is able to handle. and off_t is LONG_MAX + 1, the limit the
kernel interface is able to handle.
and
You can create a ULONG_MAX file, but with fseek, you are
only able to seek until LONG_MAX. This is the same problem as the 2GB/4GB
limit on 32bit Intel before: The file can be 4GB big, but fseek can only seek
in the first 2GB. You can go a step backward, so off_t must be signed.
-- With best regards, Carsten Hoeger SuSE, The Linux Experts, http://suse.com - http://unitedlinux.com
|
|
|