On Tue, Dec 04, 2001 at 06:14:17PM -0500, Glenn Maynard wrote:
> That's what it looked like it was trying to do. The implementation is
> confusing, though:
>
> if(takeover_time!=NO_DATE && takeover_time+1-priority>now
> && connection_limit>0 &&
> connection_limit<=CountConnections()+1)
> {
> TimeoutS(takeover_time+1-priority-now);
> goto notimeout_return;
> }
This is done for background jobs to delay the connection usage to avoid
excessive ABOR's. E.g. if you do two commands quickly, then background
job can start its own data transfer between them and it will be aborted
immediately:
get file &
ls; cd ..
With this code background session delays for 1 second before actually using
the connection.
> Is there any place something like Fg() and Bg() could be added to
> SMTask? That way, creating an object you only need to know that you
> need to override Fg(), Bg(), Suspend() and Resume(), and call them on each
> object and on the parent class, rather than things like "Fg() in a job
> should call SetPriority(1)".
No, I don't think so. Fg and Bg are Job methods, they are not applicable to
a task. Besides, base class does not know what other tasks are associated
with a derived class.
> > BTW, what do you think about caching in LsCache result of CHANGE_DIR?
>
> I didn't do this in the interests of not actually changing what was
> cached. That would cache more cases, though.
>
> If the "check the listings" method wasn't done, too, you'd add checks in cases
> where you have the parent directory cached, which is fairly common. ie.
> "cls; glob cls *". (Moderately contrived example; it's reasonable to
> anticipate GetFileInfo being used elsewhere, however.)
>
> I think it's useful to have protocol parsers readily available, though it
> doesn't matter to me if it's a FileAccess virtual or its own class. I
> used a class so there's a clean place to store things like "tz", so they
> don't have to be passed around so much; this would reduce maintenance in
> the FTP parsers if any further parameters become necessary; the rest
> followed from there. (In retrospect, it's probably not worth that much
> code.)
I have added FileAccess::ParseLongList method.
> Anyhow, with parsers easily available, this test is easy.
But it is a hint only. IsDirectory should return one of yes/no/don't know.
If one really wants to know if a file is a directory, he should call either
Chdir with verification of ListInfo on parent directory.
--
Alexander.
