I'm curious on what you're basing this assertion.  Even though the operation
is disk-bound, it seems to me that giving the disk scheduler multiple
requests may reduce latency and maintain saturation.

Cheers,

Matt Humphrey matth@ivizNOSPAM.com  http://www.iviz.com/

(piggy-backing on Remon's reply, as I can't see the original post...)

Don't do this. This is a classic example of thread overkill - there is
no benefit to using multiple threads to move a load of files. In fact,
as you have noticed, it only adds hassle - you have to worry about
concurrency issues.
What do you imagine that multiple threading will add to this task?

Also, moving multiple files simultaneously will probably be *slower*
than if you just moved them one at a time from one thread. Why is this?
Well, even just on a physical level, you will have the read/write head
of the hard disk jumping about, reading and writing itty-bitty bits of
files for each thread[1]. Whereas if you just had it doing one file at a
time, it can handle decent sized chunks of file at a time - it would be
quicker (less seek time) and would it would also entail less wear and
tear on your hard disk seek mechanism.
Also, the at a Java level, the JVM is keeping extra state and wasting
time doing context switching between threads, so it's making everything
less efficient that way.

Maybe you've thinking of doing this because you've heard that threads
are often used to do I/O - this is correct. But that tends to be just
one thread, doing some I/O on a disk, while other threads are free to do
computation and generally orchestrate things.
So, in essence, it might make sense for your program to have multiple
threads, but I would limit it to one thread only that actually does the
file moving.
A good example of when your program would use multiple threads: suppose
you want your file mover program to have a GUI that shows progress. In
this case, you'd want to a separate thread that did the file moving, or
else you'd clog up the GUI (event dispatch thread) and your app would
become unresponsive.

One of the other classic misuses of threads is when people want to write
a game, and they think: "oh, games involve independent entities doing
their own thing in a world, so I should use a thread for each game
entity". Threads aren't really applicable here though. I think the
misguided person is thinking that because game entities have their own
properties (sense of state) and they all do things simultaneously in the
game, the magic word "threads" pops up. But it's usually a mistake to go
down this route. In particular, a games engine usually wants each entity
to have its own 'go' at moving and updating its state, all in strict
lock-step, so that at the end of each game 'update' loop, every entity
has had exactly one chance of updating itself. If you did try to use
multiple threads for different game entities, various entities would
possibly proceed through the world at different rates (depending on how
lengthy their update code was!) To stop this you could use concurrency
etc. to make everything work in lock-stop. But then why bother with
threading each entity in the first place?
For a regular game, this would just be wrong.
For some things it might be more applicable - e.g. simulating lifeforms,
and wanting the slowness of their 'thought processes' (i.e. update code
length) to be reflected in the simulation. But this is not usually the
case...

Oops, I'm going off on one. Enough.

[1] ... maybe. Some of it could be affected by optimisations that could
be made anywhere from the JVM to the hard disk controller....