Training, Open Source computer languages

This is page http://www.wellho.net/forum/The-Tcl- ... guage/problem-with-fcopy.html

Our email: info@wellho.net • Phone: 01144 1225 708225

 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
problem with fcopy

Posted by sergioanis (sergioanis), 27 September 2007
hi all,
I'm having a problem using fcopy. I'm just reusing code that has been working fine for transfer .pgm and .zip files for a long time. For this 2 ext, although they are binary files I use -translation lf.
Now, I need to transfer an executable (7za.exe -from the 7z GNU project-). The file doesn't transfer properly (get corrupted and doesn't execute). I tried with -translation binary; and combinations of lf and crlf according to the 'in' and 'out' for each side, with no luck (although I can see the size of the file transferred change, the size sent by the server is always the same and identical to the size of the file storage in the server)

below is the working code for .pgm and .zip files.
I'd appreciate any help, either to make it work or another way of transfering the file automatically if needed by the client

thanks,
Sergio


on the client side (OS: W2K)

if { ![ file exists $unzipper ] } {
   set serverpath $config(raw)/7za.exe
   set out [open $unzipper w+]
   ClientSend sendfile $serverpath    ; #send the command to the server
   set in $config(server)
   fconfigure $in -translation lf
   fconfigure $out -translation lf
   fcopy $in $out
   close $in
   close $out
   }
####################################            
on the server side (OS: Unix)
     
proc SendFile { filename } {
     global server
     global total
     set in [open $filename]
     set out $server(client)
     fconfigure $in -translation lf
     fconfigure $out -translation lf
     fcopy $in $out -command [list CleanPort $in $out]
     vwait total
     return
}
proc CleanPort { in out bytes { error {} } } {
     global total
     set total $bytes
     close $in
     close $out
     puts "Transferred $total"
     if {[string length $error] != 0 } {
           puts "CleanPort fcopy error $error"
     }
     return
}

Posted by admin (Graham Ellis), 27 September 2007
I would look at the actual transfert size and see what pattern there is for further clues, or use somehing like od to look at the individual bytes.  "Truncates at null" or "New lines become return, newline sequence" would be a much more specific issue to fix than "file size changes"

Posted by sergioanis (sergioanis), 27 September 2007
hi Ellis,
can you specify how to look at indivual bytes,  "Truncates at null" or "New lines become return, newline sequence". I didn't know you can do that on binary files.

thanks,
Sergio

Posted by admin (Graham Ellis), 27 September 2007
On the Linux / Unix side - the one I know best - use the od command,  with the -c option.   To check the files as they are on the Windows box ... there is probably a utility, but I would FTP tem to Linux (making sure I'm in Binary mode) and od 'em too!

Posted by sergioanis (sergioanis), 28 September 2007
hi Ellis,
I found that using translation lf and binary I get the same files (no differences on size nor content).
Both files are bigger than the original (476672 vs 476683 bytes).
I couldn't make much sence of the differences (there are too many), if you want I can email you the files.

What I did see is the word 'data done' on the first line of the transferred file. The work flow is:
1. login, password, etc
2. transfer a zip file ('data done' is sent when the transfer finish)
3. transfer the 7za.exe if it doesn't exist

so, I'm thinking that may be is a buffering problem; but I don't quite get how can be possible: 'data done' was already sent, otherwise it wouldn't continue to the step 3

Any ideas?
thanks for your help
Sergio

Posted by admin (Graham Ellis), 29 September 2007
on 09/28/07 at 14:28:09, sergioanis wrote:
Both files are bigger than the original (476672 vs 476683 bytes).
I couldn't make much sence of the differences (there are too many), if you want I can email you the files.

Any ideas?


"No thanks" to the email - we're very much set up to provide pointers rather than to put large dollops of time into going through nearly a meg of data.

There is a clue, perhaps, in the 11 bytes difference.   Look for PATTERNS.  With different files transferred, is the difference always 11 bytes?  And when you look at the byte by byte data, have you tried to "synconise" it 11 bytes offset?   Checked whether you've simple got 11 extra bytes on the start of one file?



This page is a thread posted to the opentalk forum at www.opentalk.org.uk and archived here for reference. To jump to the archive index please follow this link.

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho