Description Martin Oberhuber 2008-01-23 16:55:41 EST

Directory retrieval may be a long-running operation, especially if lots of file classifications and/or symbolic link expansions take place.

This can best be shown with an SSH connection to a remote directory where lots of symbolic links point to NFS directories on servers that are currently down (each of these produce a 5 second timeout): show the Progress View -- although the fetch operation takes a long time, and is cancelable, no progress is shown.

The problem is, that in the hierarchy of callers it is unclear who is responsible for performing the monitor.beginTask() operation, and how many prgress ticks each task should have. There is a need to define this behavior as API.

To find the culprits which originate the progress monitors without tasks, place a breakpoint in SftpFileService#progressTick() then expand or refresh the directory. I'm finding the following:

SystemView$RestoreRemoteObjects#run()
AbstractSystemViewAdapter#fetchDeferredChildren()
   -- delegates to:
SystemFetchOperation#run()
   -- does a beginTask(100) but passes on a subMonitor without it

and probably more. It looks like a task with 100 progress ticks to use should be passed into the fetchDeferredChildren() method; but the problem is, that beginTask() should only be called ONCE for each monitor, and there might be other routes with other monitors e.g. connect() and similar.

So, where should the beginTask() occur?