After updating to proftpd-1.3.0-r1, ftpwho does no show any transfer progress. It is because the scoreboard file, is not updated with xfer done info. The problem seems to be connected to the --enable-sendfile option. If proftpd is compiled with --disable-sendfile, transfer progress is updated again during transfers. The problem also exists on the amd64 platform. emerge --info: Portage 2.1-r2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17.11 i686) ================================================================= System uname: 2.6.17.11 i686 Pentium III (Coppermine) Gentoo Base System version 1.12.4 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.linux.ee/pub/gentoo/distfiles/ http://trumpetti.atm.tut.fi/gentoo/ ftp://ftp.du.se/pub/os/gentoo http://ftp.du.se/pub/os/gentoo" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 X apache2 berkdb bitmap-fonts bzip2 cdr cli ctype cups dlloader dri fam fortran gd gdbm gpm gtk imagemagick imap isdnlog jpeg kde ldap libg++ maildir mhash mozilla mysql ncurses nls nptl nptlonly nsplugin opengl pam pcre perl php png posix ppds pppd python qt readline reflection samba session spl sqlite ssl tcpd threads tiff truetype truetype-fonts type1-fonts udev unicode usb xml xorg zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en userland_GNU video_cards_radeon video_cards_fglrx video_cards_vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Well, sendfile is enabled by default, you should bug upstream if it's broken. You can stick this into the ebuild and re-introduce the flag, should work. <snip> # sendfile needs to be explicitely disabled as well use sendfile || myconf="${myconf} --disable-sendfile" </snip>
OK, reported it upstream: http://bugs.proftpd.org/show_bug.cgi?id=2838 Let's see if this is a proftpd bug or if it should behave like this...
Normal behaviour. Changing to INVALID.
