Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
20.9.2014 - We have just updated our course layouts and descriptions and added our 2015 schedule.

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.

You can Add a comment or ranking to this page

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