javascript - SFTP SSH_FXP_READ Offset -

i'm writing sftp server in node.js, i've run strange issue @ final hurdle, reading files… pretty obscure topic appreciated.

following version 3 sftp spec here: https://filezilla-project.org/specs/draft-ietf-secsh-filexfer-02.txt

i've been testing server filezilla, coda2 , command line sftp on osx. each has been successful in functions until reading include 64 bit communication, each seems produce different weird behaviour when reading files.

according spec (section 6.4), ssh_fxp_read should provide:

uint32     id <- request id string     handle <- file handle uint64     offset uint32     len 

which come through valid id , handle, offset , length different matter. i'm using 2 byte handle here simplicity.

coda expected: 5 ff 0 30000 6 ff 30000 30000 7 ff 60000 30000 8 ff 90000 30000 etc until eof  coda real: 5 ff 0 30000 6 ff 30000 30000 7 ff 27232 30000 8 ff 89872 30000 9 ff 87104 30000 10 ff 149872 30000 

coda gets first 2 right loses it...

now first thought i'd read 64bit offset wrong:

(buf.readuint32be(0) << 32) + buf.readuint32be(4) 

edit: changed bitshift example 32 8 (still not working), tried node-bignum , node-int64 identical results

javascript's 53 bits of precision here should enough file sizes right?

so verified reading python unpack (">q") , correct. not same 64bit handlers communicating file sizes in ssh_fxp_readdir , ssh_fxp_stat fine..

so lets try different client, can't worse right?

filezilla doesn't request length on first chunk , instead request whatever length server returns on first chunk. regardless of length of returned data, offset seems incremented 65536 bytes or more…

the thing can think of reading 64bit buffer wrong, reading them hand it's wrong:

<buffer 00 00 00 00 00 00 75 30> expected:30000 got:30000 <buffer 00 00 00 00 00 00 6a 60> expected:60000 got:27232 

we're getting errors before breaks 32 bits.

now if ignore offset , length , stream file client in chunks on each read request , serve eof status when complete, works fine in clients. disregards spec bad idea.

unfortunately there isn't relevant code post seems pretty fundamental problem.

any ideas or insight appreciated. @ point don't care if elementary mistake :)

javascript's bitwise operators work in 32-bit values. can instead use multiplication/division, in sftpv3 client in ssh2.

also point out, (buf.readuint32be(0) << 8) shifting 4 bytes 1 byte left instead of 4 in order make room other 4 bytes of 64-bit integer.