[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#265819: marked as done (libc6: sendfile64() should fall back to sendfile() if not implemented by the OS)

Your message dated Sun, 22 Apr 2007 22:12:28 +0200
with message-id <20070422201226.GA5568@amd64.aurel32.net>
and subject line Bug#265819: libc6: sendfile64() should fall back to sendfile() if not implemented by the OS
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: libc6
Version: 2.3.2.ds1-16
Severity: normal

(Not filing as wishlist because, well, it's a bug.)
If sendfile64() fails because the underlying OS doesn't implement it (as
linux 2.4.x fails to do for a number of architectures), it currently
just breaks.  If large file support is turned on, then there's no way
for user applications to fall back to normal sendfile().  Since glibc
already takes care of replacing sendfile() calls w/ sendfile64(), it
should also handle calling sendfile() if sendfile64() isn't implemented
by the OS.  



-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-k7
Locale: LANG=en_US, LC_CTYPE=en_US

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-7    The Berkeley database routines [gl

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 2.5-3

On Sun, Aug 15, 2004 at 10:04:10PM -0400, Andres Salomon wrote:
> On Mon, 2004-08-16 at 09:23 +0900, GOTO Masanori wrote:
> > At Sun, 15 Aug 2004 03:02:47 -0400,
> > Andres Salomon wrote:
> > > (Not filing as wishlist because, well, it's a bug.)
> > > If sendfile64() fails because the underlying OS doesn't implement it (as
> > > linux 2.4.x fails to do for a number of architectures), it currently
> > > just breaks.  If large file support is turned on, then there's no way
> > > for user applications to fall back to normal sendfile().  Since glibc
> > > already takes care of replacing sendfile() calls w/ sendfile64(), it
> > > should also handle calling sendfile() if sendfile64() isn't implemented
> > > by the OS.  
> > 
> > Do you have a test case?
> > 
> > Regards,
> > -- gotom
> > 
> 
> Currently, apache2 is our test case.  Adam Conrad or myself will send
> you a smaller test case, post-sarge; in the meantime, this bug can wait.
> 

Starting with the version 2.5, the glibc requires a 2.6 kernel, thus the
sendfile64 syscall is always available.

I am therefore closing the bug.


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

--- End Message ---
Reply to: