#5 temp file in .MultiGet user directory

open
nobody
None
5
2007-08-25
2007-08-25
pelasgian
No

The temporary files should not exist to start with, but even if you have to, they should be in the same directory as the download file or they should be user definable.

I have my /home in a small partition and I download in another very large partition. An iso of 4.7 won't fit in the /home partition under /home/user/.MultiGet, and the program makes no checks whatsoever for filelengths and partition capacity.

As a result it consumes all space in /home and then freezes, ALTHOUGH there's space in save-file-directory. This is a bug (and a very inconvenient one as I had to move the entire directory to destination partition and link back to it in my /home/user)

In addition, if the save dir is in ANOTHER volume/partition, it has to COPY the whole stuff there, not that it leaves the temp files there after download. This is not very efficient.

Don't even think of using as temporary the /tmp, because there are people (like me) who have /tmp in a ram-drive.

Some interface remarks: Don't write things like File(F), Task(T), View(V) Option(P), Help(H). Just underline the letter of the shortcut as EVERYWHERE else. It looks really bad.

Also, the indication bar is scrolling the other way around than typical, e.g. gkrellm, and it only allows for 300K/s and 900K/S. How about permitting a user defined scale? It took my a while looking at gkrellm to figure out why your bar showed steady max speed, while in reality it had flactuations above 300K.

I write all that because I *REALLY* like your program, not as criticism (in case this is not so obvious). Other that these problems the program is very fast and useful.

How about writting a command line program as well? For instance a wget that takes multiple sources?

All the best and thanks!

Discussion


Log in to post a comment.