| |||||||||||
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:
"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.
|
| ||||||||||
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho |