Making RTS/FFS instances more polite

[dwig]

I've got 8 instances of RTS running in the systray, occasionally spawning FFS
instances (sometimes up to 5 or 6 at once, more often 2-4). I've set things up
so they all run at "idle" priority (with a script that runs at startup time).
Even at this low priority, I often notice that the FFS jobs occasionally hog
the computer for a while (particularly when multiple instances are running at
once). As a workaround, I'll restore and pause them (one at a time, of course)
until it's convenient to "unleash" them again. I have two requests:

First, I suspect that some operation during the file scanning and copying
occasionally blocks, keeping other things from running. If this is the case,
it'd be nice if you could find a way to keep it from blocking, or maybe add a
"yield" in appropriate places.

Second, and less desirable, I'd like a way to manage the instances from a
script or app I'd write. Basically, I'd want to be able to do the equivalent
of Restore/Pause to each FFS instance with a single command to the script,
then Continue and Minimize with another. I'd probably write it in Python with
the win32 api, so I can probably deal with fairly low-level operations. (If
you can deal with the first request successfully, this wouldn't be needed.)

Before I forget, thanks again. I'm finding this app to be very useful; it
gives me a solid feeling that my files are properly backed up. I'm logging to
a folder, and I've added a bit to the startup script that zips up the logs
older than a couple of days to keep the number of files and disk space down.

[Zenju]

> they all run at "idle" priority
Setting idle priority won't help because this has an impact on CPU consumption
only. FFS on the other hand is file I/O bound, consequently this setting won't
have much effect.

> maybe add a "yield" in appropriate places
Yield is only useful to keep a single process responsive. If the whole windows
session blocks this is due to hard disk I/O being at the limit. FFS itself
calls yield ever 100 ms and should be responsive all the time. (well almost,
except for first recycle bin access and initialization of VSS)

> could find a way to keep it from blocking
There indeed is a way to limit I/O: Beginning with Windows Vista it's possible
to categorize a process as "background/batch". However performance is severely
hurt with synchronization taking twice the time. So this definitively won't be
set as a default.

> manage the instances from a script or app I'd write.
I'm not sure it's worth the hustle to create an API for external use for such
a tiny feature. But what's already working is a simple "taskkill" on RTS
instances followed by a later restart.