Queue copy (concept and discussion)

[Igor Morgado <igormorgado listas gmail com>]

Hail sailors!

Yesterday, came to me a mind boggling thing, while doing my personal
music selection to be copied to my N85, i have stopped with a problem.

My N85 can handle lot music (8GB). And I wish to fill out, not only
with a single band or single albun, I wish to copy many files
scattered in a bunch of directories (I have a 180GB repository). Since
I cannot have 2 group of files in copy clipboard at same time, I have
to start a copy, and change dirs, and start another copy, often this
copies happens simultaneously, and this works likes a snow ball, going
to a point that we call (in system tunning) saturation point, when
youre have more simultaneous file operations than your I/O device can
handle, raising all queues (VFS, FS, Bus, Card, Disk, Head), and
dropping our average througput (in theory sata can handle 2gb/s), but
with 10 simultaneous file operations, no more than 10kb/s can be
reached, cause the disk head need to move A LOT.

Ok, I can copy one pack of files, wait the copy finish, copy another
pack, and goes on, think to fill a 8gb disk will take a while (and I
will lost all my busy day in this lovely task).

Since Im not satisfied with the second option, I thought, why not
write something to handle that? And I did. I wrote a simple nautilus
script with a simple interface in python-gtk (i can share it, not
aproblem) to do the following:

1. Nautilus script "tag" the files to be queued with a file name
simple redirection to a control file
2. this control file stores all files names that I want copy,
3. with a simple pygtk interface, I open this file in grid where I can
START, STOP, and schedule the copy, then I do my "queue copy" with
basic filesystem operations

This task works fine, but isnt a elegant solution, then im not
satisfied with that too.

Then I came to #nautilus and #gnome channels and asked for guidance in
how to handle that in a more gnomewise way. What Im thinking:

In first view I will remove the interface from user. In first glance
users copy from same SOURCE_DEVICE x DESTINATION_DEVICE should NOT be
done at same time, they should be queued, in a overall this drops the
i/o througput to floor, doing 2 simultaneous copies at same time in
same device is slower than do one copy then another. Raising the
number of simultaneous copies will make this time raise in a
exponential way. And makes the system locks, since concurrence to load
applications virtual images from disk, and swap operations will be on
disk queue.

BUT, this point of can be too much radical for some ppl here, and I
though to add a shortcut to point my will to do the queue not direct
copy, example, dragging and dropping will copy, drag and drop with ALT
key pressed makes a queue copy (of course the shortcut can be
changed). Or I can set in a gconf key,  flag 0 no queue at all, flag 1
optional queueing (with shortcuts or something else), flat 2 (always
queueing, shortcut will disable the queue). Of course creation of
icons to identify that copy will be queued or not should be added for
sake of user.

Adding more features, I thought in change the default gnome file
operations window (that opens when we do  file operations), the user
should be able to see the queueing status, be enable to pause,
restart, cancel, and start file operation or schedule the operation to
sometime in future.

I want to discuss some things here:

1. Is that a good ideia? or not?
2. Someone else is already planning on do that? or is already doing that?
3. What is the more gnomewise way to do that?
4. Where can I read more about the things to do that (i have a fair
knowledge in C and Python)
5. Any changes to make this a damn good ideia will be welcome.

IMHO, I think that is a must to any user interface, in today
computers, everyone has a lot of disk (we talking about 1TB in a
single desktop computer), doing things as hand made backups, or mp3
file copy, of simple file system organization in a environment where
all file operations happens in same time, makes the system unusable.

That is it. Any ideas are welcome. Im willing to write that.