On Wed, Dec 05, 2001 at 08:16:59PM +0300, Alexander V. Lukyanov wrote:
> > (fixes to GetFileInfo.cc withheld until caching is sorted out)
>
> I have applied the IsDirectory patch and modified it according to
> FileAccess::ParseLongList. Why don't you like alloca? It is quick
> and the memory if freed automatically.
I'm just not in the habit of using it. (Usually, not doing local allocation
is a better solution; ie. string objects.)
On Wed, Dec 05, 2001 at 07:39:46PM +0300, Alexander V. Lukyanov 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:
I understand the reason for the delay; I don't understand the way it's
computed. It looks like it'd be weird if you had jobs with priority > 1.
Nothing does this, so this +1-priority formula works out; if this isn't
intended to work with that, it'd be clearer to do something like
TimeoutS(takeover_time-now + (high_priority? 1:0));
> > 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.
I know that Fg and Bg don't apply; that's why I said "something like".
I'm not sure what you mean by the second sentence.
Anyway, it doesn't really matter to me. I'm just suggesting a way to
simplify it, since it's not obvious that this type of thing needs to be
done; it doesn't affect me, since I know now ...
> 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.
That's what it does. 1, yes; 0, no; -1, don't know. Sorry, that's
worth commenting. (Which I see you've done.)
How important is calling session->Close() between operations? Things
seem to do it after a successful Chdir(), before doing other things.
I've changed GetFileInfo to call it where it seems appropriate, modelled
after FileInfo, MirrorJob, etc.
--
Glenn Maynard
