On Sun, Nov 04, 2001 at 03:34:06PM -0500, Glenn Maynard wrote:
> StatusLine is blocking; this causes all transfers to stop if its
> printf()s block. It should probably go through some buffering layer.
Maybe. But I would prefer status line updates to be atomic, so that
other tty output would not break it in half. No big difference, actually.
BTW, other tty output in lftp is blocking also. I remember that
making tty non-blocking can cause funny side effects in other programs.
So, e.g. `cat' command can also block other transfers.
> 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.
There is already class IOBufferFDStream.
> 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 think Buffer is an appropriate base class for CopyPeer. I know that
the copying thing is not simple, but the buffering is needed anyway.
> 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 ...)
Is global buffering is really needed? Maybe it is better to have a separate
buffer in each job, like it is done now.
> 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.)
Ok, I'll finish the time stuff and release 2.4.7.
> There're a bunch of really old (Debian) bugs listed that can probably be
> closed--some nearly two years old.
Sure.
> #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)
I think he was misleaded by the fact lftp used to default to anonymous
password with leading minus sign. It supressed multiline server messages.
Now the minus is not used by default.
> #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)
2.4.1 does use LIST too. It was long ago when I moved to LIST from NLST.
NLST is still used if LIST cannot be parsed.
> #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.
I'll check it.
> #77201: ftpget is missing
> Package: lftp; Reported by: "Christian T. Steigies" <[EMAIL PROTECTED]>; 353 days old.
> There is no ftpget anymore ...
A replacement script compatible with ftpget is distributed, but not installed
by default. Look for src/ftpget.
> #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 ...)
Debian distributed lftp with alias ls "ls -CF" which confised many users.
> #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
Some servers implement SITE UTIME, but it is not common. You can create
empty files with `put -c /dev/null -o file', but it won't touch existing
files.
du is useful indeed. Use FinderJob as base class.
> 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.
I already treat ENFILE and EMFILE as non-fatal. Maybe ENOSPC should be
treated similarly.
--
Alexander.
