From: Wietse Venema (no email)
Date: Mon Sep 01 2003 - 14:56:10 EDT
Carsten Hoeger:
> 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.
You mean, all the world is a PC so you don't care?
> Why do you fall back to INT_MAX?
Postfix falls UPWARDS to INT_MAX. Look at the code.
> > > 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.
Again, how portable is this? I know of no standard that requires
getrlimit() to return values limited by ULONG_MAX.
In fact, I see rlimit structures that can handle much larger types
than long integers, for example:
struct rlimit {
rlim_t rlim_cur; /* current (soft) limit */
rlim_t rlim_max; /* maximum value for rlim_cur */
};
where rlim_t is a 64-bit type. And this is on a 32-bit box.
There are several changes in after-2.0 Postfix snapshots to go from
long file offsets to off_t file offsets, so that mail can be
delivered to files >2GB on systems with 32-bit integers. The next
step is to introduce a new configuration parameter type for off_t
like applications so you can specify limits > 2GB on systems with
32-bit integers.
In any case be sure to come up with something that isn't completely
dependent on accidental non-portable system implementation details.
Wietse
|
|
|