Sorry, I think you'll have a lot to come back to from wherever you've
gone. :)
First, the minor stuff:
StatusLine is blocking; this causes all transfers to stop if its
printf()s block. It should probably go through some buffering layer.
We can stall status updates. For example, if someone using lftp over a
modem accidentally hit ^S before a transfer, and then ^Q after, he'd get
blasted with the entire set of updates that he doesn't need. (It'd also
take buffer space the whole time.) We can stop sending updates once it
starts blocking. We'd still need to buffer whatever wasn't sent, so we
don't send a partial status line. (This is "wishlist" class, of course;
just getting it nonblocking to prevent stalling is all I'd call a bug.)
Hazy wishlist stuff:
I could see having a low level, buffered FDStream-like class, and having
all stdout access layer on top of that. (This would include
FileCopyPeerFDStream.) It wouldn't be bad if the buffer of a FileCopyPeer
wasn't a derivation--if there was a member Buffer with virtual access to
it; as is, it'd mean a lot more IO as things get shifted between buffers.
I personally don't like FileCopyPeers being derived from Buffer--it mixes
calls and gets a bit confusing for those of us who didn't write it. It's
more of a has-a than an is-a, to use annoying textbook terms. I'd be
interested in hearing your opinion on this. (You wrote it, after all. :)
I'm going to give this a bit more thought--it's more hassle than it's
worth unless it's generalized more, due to issues with mixing buffering
and not (like mixing fds and FILE *s). If it's generalized, we don't
have to worry about it (except to flush before going back to readline);
if *all* access to stdout ultimately went through the same object. This
is incompatible with the FDStream paradigm ("create another object with
the same FD") unless copy-on-write methods are used--which might be
something to consider, too. (It's easy, since we're not threading ...)
Okay, I'll back-burner the above stuff and think about it some more. I
don't want to do any major changes right now, anyway. :) Personally, I'd like
to see the current minor issues (ie. mget -E's crash) fixed, and get Debian's
package updated; it's still 2.4.1. (Looks like the maintainer's absent--not
responding to Debian bugreports on it. I'll give him a poke, after the
current bugs are fixed--not including the above--and if I can't get
anything out of him I'll consider bringing it up on debian-devel or
whatever the appropriate list is, unless you'd rather do that yourself.)
Other stuff:
There're a bunch of really old (Debian) bugs listed that can probably be
closed--some nearly two years old.
Going through bugs (not all of them):
#62221: does not display server messages even with debug on
Package: lftp; Reported by: Kevin Turner <[EMAIL PROTECTED]>; 1 year and
207 days old.
(does now)
#63276: lftp: NLST should not be used for getting TAB-completion filenames
Package: lftp; Reported by: Oskar Liljeblad <[EMAIL PROTECTED]>; 1 year and 189 days
old.
(we use LIST now; closable once they upgrade)
#65460: lftp: crash during filename tab completion
Package: lftp; Reported by: [EMAIL PROTECTED]; 1 year and 148 days old.
Hey, I know that guy. (Er. Fixed long ago.)
#67027: lftp 2.2.3 does not build using apt-get source
Package: lftp; Reported by: "G�bor" "Lipt�k" <[EMAIL PROTECTED]>; 1 year and 117
days old
2.4.1 does, though the "testroot" part fails and the build stops if you're
not root; I'm not sure if that's the intent. I'll look at it later.
#63507: mget -d directory doesn't work
Package: lftp; Reported by: exa <[EMAIL PROTECTED]>; 1 year and 186 days old.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=63507&repeatmerged=yes
This still happens.
#77201: ftpget is missing
Package: lftp; Reported by: "Christian T. Steigies" <[EMAIL PROTECTED]>; 353 days old.
There is no ftpget anymore ...
#87656: /etc/lftp.conf broken for some FTP servers
Package: lftp; Reported by: Neil Schemenauer <[EMAIL PROTECTED]>; 251 days old.
and
#111956: lftp: ls/dir aliases in /etc/lftp.conf break minimal ftp servers
Package: lftp; Reported by: <[EMAIL PROTECTED]>; 54 days old.
There's no -CF default to ls anymore. (Doesn't need to be; cls
obsoletes that ...)
#95679: lftp: segfault with bad url types
Package: lftp; Reported by: [EMAIL PROTECTED]; 189 days old.
Doesn't happen anymore.
I skipped a few, I didn't touch the wishlist ones, and there's one
Important one that's fixed past the version in Debian. Once we fix
the few current issues, I'll send another maintainer-poke, asking him to
close the above bugs (except 67027 and 63507) when he upgrades the
package.
I'm considering implementing "touch" and "du", by the way. Is there a
"set modified time" FTP command? I mainly want touch to create 0-byte
files, but having it update the MDTM of existing files would be good,
too. Lacking that, perhaps have it "resume" an upload of the same
length--some FTP servers will probably choke on that, though ("why are
you resuming a file that you claim is already complete?")
Last one: writes to disk failing are fatal, including "disk full". It'd
be nice if that was an option: treat local write errors as retryable
operations. I've had entire queues lost due to this (tries a file,
fails, tries the next, fails, emptying the queue.) I don't know if some
people would prefer local errors to be fatal.
--
Glenn Maynard
