gplink 1.2 is out!

[Vince]

Hail to you all! :rolleyes:

I am very happy to announce the release of the 1.2 version of linux gp32 usb transfert program with a big new feature : large file size support (thanks to Ulrich Hecht) !

I proposed myself to take over the development of gplink, originally written by Mike Dawson. This release is a startup for me (real first GPL project, really happy to get in .

I integrated, as well as Ulrich's patch, a few things I thought needed : -h flag in info command and a better progess indicator (shows total file size as well as percentage)

Do not hesitate to drop me a word and report bugs. I am hesitating about the next feature to implement : dired info command or autocompletion (seems harder IMHO). I may start a poll about that.

Enjoy,

Vince


PS: The biggest file I sent so far is the archive of jakarta struts (just found it in a corner which is 16megs large. No problem encountered.
PPS: you may need the link. Here it is http://vincent.rubiolo.free.fr (sorry for the very minimalistic page)

 

[Robster]

Nice work, thanks!

I can't try it out till I get home from work, but this will be very useful for me.

An idea for another enhancement: how about adding direct upload and run of gxb files? This is supported by the pc-link part of multifw2, and also by the pclink.fxe that's available from Dark Fader's site.

There is a stand-alone linux program, GpRun, which does the upload and run but doesn't do anything else... you can get the source for that at mithris' site.

Apparently multifw3 will support direct upload and run for fxe files as well

 

[woogal]

Large file support doesn't work for me I'm afraid
A 5MB file pauses for a few seconds at just over 3MB, but instead of continuing it drops out with 'error reading from bulk endpoint 0x81: Connection timed out' (gplink 1.1 gives the same error). A 100MB file just pauses then shows that error without transfering anything. Smaller files still work as normal.

 

[Vince]

Hiya,

Did you check that the file hasn't got a too long filename?. Sometimes weird things happen in such a case. You can use the -c option to truncate filename but I'm not sure it is completely reliable. I plan to improve that.
Another thing : is it happening with the static binary or the one you compiled yourself?
Finally, could you give the version of libusb you are using (as well as usbdevfs one)?

Quoting from what you observe, the pb might come from the loading of the file in memory, before transfer starts. I'll make more tests and tell you what happens.

Vince

 

[woogal]

One file had an 8.3 name, the other didn't. Tried using -c but it failed (filename contained spaces if thats any help to you), so renamed the file to an 8.3 format. Tried your binary first, then compiled my own. Both had the same results.

libusb is 0.1.7, kernel is 2.4.22

And my suggestion for next features would be multiple file upload (wildcard matching) with recursion. That would make me very, very happy

 

[Vince]

Hello,

Upgraded to 0.1.7 version of libusb and cannot reproduce the pb (kernel 2.4.20-8 RH). I've tested dling struts and giro and it worked well. I still need to empty my SMC to be able to dl huge files as you did.

I cannot see the pb so far. Can you provide more info about what is happening (cat /var/log/messages would help, as well as a precise scenario on how to reproduce the bug with an easy to find problematic file).

ROBSTER : did you encounter the same pbs?

Vince, holding the line

 

[Vince]

Yo men!

Are you still alive? Nobody was able to give me a more detailed description of the problem!

Since it's working for me, I put the pb on hold and continue working on the project. At the moment, I'm studying bash sources to learn how to make autocompletion (the next feature, I think, closely linked to recursive reading/uploading)

Cheers,

Vince