[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: file read problem
- From: "Mark Meijer" <meijer78@...>
- Date: Wed, 16 Nov 2005 09:21:25 +0000
Hi all,
For some reason, reading in an entire file, for example with simple test
code like this, doesn't appear read the whole file:
local file = io.open("infile", "r");
if(file) then
local data = file:read("*a"); -- i've also tried "*all" as described in
PIL
file:close();
file = io.open("outfile", "w");
if(file) then
file:write(data);
file:close();
end
end
So far, I have used lua in a couple of projects but never noticed this
problem before, although I'm not sure that I've actually used this specific
functionality before. When the data is dumpwritten to a new file, it is way
too small. Writing string.len(data) to the output file instead, also shows
this same (too small) size, so that would indicate the problem is either in
reading the file, or simply in determining the length of the resulting
string in memory (be it in the call to file:write or to string.len). But the
latter doesn't seem likely as lua keeps explicit record of the length of a
string, so I suspect the problem is somewhere in reading the file.
The file where the data is written to does contain the actual data of the
file that was read, it just seems to be truncated (one example case was a
500KB file being read and resulting in a 9KB file, approximately). The
resulting output file size is consistent between runs for the same input
file, but it's different for different input files.
I'm using lua 5.0.2 and compile it into static libraries, and include the
luasocket and luafilesystem libraries into the build, also static. My app is
single-threaded and I link everything to the single-threaded static
run-time. So, everything is statically linked and I end up with one big
self-sufficient executable. I don't use any funny compiler options (as far
as I know, I just made my own project from the VC6 IDE and set optimisations
either to maximize speed or minimize size). I still need to do a debug build
of the library and trace through the code to track down the exact location
of the problem, but I was wondering if anyone might have had this problem
before, or might know a likely cause.
Thanks,
Mark