What limit have I run into?

[vefatica]

This BTM will copy a file.

setlocal
set nReadSize=2045
set nReads=%@eval[ceil(%@filesize[%1]/%nReadSize)]
set hIn=%@fileopen[%1,r,b]
set hOut=%@fileopen[%2,w,b]
on break goto close
do i=1 to %nReads
    set junk=%@filewriteb[%hOut,-1,%@filereadb[%hIn,%nReadSize,x]]
enddo
:close
set junk=%@fileclose[%hOut]
set junk=%@fileclose[%hIn]

If I change nReadSize to 2046 (and use a file bigger than that) it fails as follows.

The DO loop never terminates. And, each time through the DO loop what's written to the output file is: the first 2046 bytes of the input file followed by 0x40 0xFF.

What's happening? [It's a counted DO loop so I can't understand how it could fail to terminate regardless of whether the file read/writes are correct.]

 

[Charles Dye]

If only there were an internal command to copy files. We could call it... PIP.

 

[vefatica]

The do loop would terminate correctly but it seemed to go on forever because @FILEWRITEB went haywire. Maybe this will shed some light on what's happening. Here is a single manual read/write of 2045 bytes; all seems well. The DATA variable has the form "0xHH 0xHH ..." so the lengths are correct.

v:\> echo %@repeat[x,2050] > in.txt

v:\> set hin=%@fileopen[in.txt,r,b]

v:\> set hout=%@fileopen[out.txt,w,b]

v:\> set data=%@filereadb[%hin,2045,x]

v:\> echo %@len[%data]
10224

v:\> echo %@filewriteb[%hout,-1,%data]
2045

v:\> echo %@fileclose[%hin] %@fileclose[%hout]
0 0

v:\> dir /k /m in.txt;out.txt
2020-10-15  15:18           2,052  in.txt
2020-10-15  15:20           2,045  out.txt

Here's the same for 2046 bytes. It takes a while because the one @FILEWRITEB actually writes 67,580 bytes!

v:\> set hin=%@fileopen[in.txt,r,b]

v:\> set hout=%@fileopen[out.txt,w,b]

v:\> set data=%@filereadb[%hin,2046,x]

v:\> echo %@len[%data]
10229

v:\> echo %@filewriteb[%hout,-1,%data]
67580

v:\> echo %@fileclose[%hin] %@fileclose[%hout]
0 0

v:\> dir /k /m in.txt;out.txt
2020-10-15  15:15           2,052  in.txt
2020-10-15  15:16          67,580  out.txt

 

[Kachupp]

It all works fine if you specify "1" data=%@filereadb[%hin,1,x] or am i missing something

 

[vefatica]

It all works fine if you specify "1" data=%@filereadb[%hin,1,x] or am i missing something

It works for any read size up to 2045. The point is that it doesn't work for 2046.

 

[rconn]

You're running into the 2K limit on the number of arguments to a function.

 

[vefatica]

You're running into the 2K limit on the number of arguments to a function.

Can I work around that by quoting ... will @FILEWRITEB remove the quotes and proceed?

 

[vefatica]

On second thought ... I don't understand. @FILEREADB gives a space-separated string of ASCII character numbers. And that string goes directly to @FILEWRITEB (as third parameter). Are the spaces then considered parameter separators?

 

[rconn]

Yes, the spaces are parameter separators.

Since this is undoubtedly the most fantastically inefficient way imaginable to copy files, I presume you actually want to do something else and this was just an example of the problem.

 

[vefatica]

Yes, the spaces are parameter separators.

2K parameters seems to be a problem only for @FILEWRITEB. I haven't tried too hard but I can't find another variable function which chokes on a string with 2048 spaces in it. Below, the variable zz contains 0 1 2 3 4 ... 2047 2048. Can't @FILEWRITEB simply be made to behave better?

v:\> set zz=0

v:\> do i=1 to 2048 (set zz=%zz %i)

v:\> echo %@len[%zz]
9134

v:\> echo %@words[%zz]
2049

v:\> echo %@right[10,%zz]
 2047 2048

v:\> echo %@instr[9,-10,%zz]
 2047 2048

v:\> echo %@word[2047-,%zz]
2047 2048

v:\> echo %@regex[2047,%zz]
1

v:\> echo %@wild[%zz,*2047*]
1

v:\> echo %@tspace[%zz]
2048