It's not exactly a bug, it's more of an unfortunate side effect of trying to mimic the AMOS distinction between contiguous/random files and sequential files. (In DOS, Windows, and UNIX, there is no such distinction.)
So, in the default mode, if a file does not contain an exact multiple of 512 bytes, then we can be pretty sure it is a "sequential" file and LOOKUP returns a positive value for the number of blocks (rounded up), as does AMOS.
But in the case where the file happens to be an exact multiple of 512 bytes, A-Shell just guesses that it is most likely a random/contiguous file and returns a negative value in LOOKUP, like AMOS does. Of course, there is nothing preventing a sequential file from having an exact multiple of 512 bytes, so sometimes this guess is wrong. (It's also possible to be wrong the other way, i.e. for a file that is always accessed as a random file to not have a multiple of 512 bytes; as an example, ISAM-PLUS data files have this characteristic.)
The recommended way to deal with this issue is to add
OPTIONS=ABSLOOKUP to the miame.ini, which will cause LOOKUP to always return a positive value. (This at least eliminates the need to worry about handling either case, although you may have old code that just assumes that a LOOKUP on a random file returns a negative number, in which case this option will make things worse.)
Another solution is to forget about "blocks" (which don't really have any meaning any more, given that modern disks typically allocate at least 2048 bytes at a time, and UNIX/Windows/A-Shell allows reading/writing "records" of an arbitrary size without the need for "blocking". (Although to get that effect, you need to add
span\'blocks to your OPEN statements, or specify a record size > 512.) In place of "blocks", you can use XCALL SIZE to get the size of files in bytes.
But you may have to scan your code for all occurrences of LOOKUP to see whether you make assumptions or distinctions about negative vs positive return values and fix them manually.
