On Friday 08 February 2008 08:44:36 Jacques Verryn wrote:
> On Feb 5, 2008 11:49 PM, Rob Landley <[EMAIL PROTECTED]> wrote:
> > On Tuesday 05 February 2008 10:13:13 Jacques Verryn wrote:
> > > The crux of the problem is if I scp a file from my desktop linux pc to
> > the
> > > gumstix, the resulting file on the gumstix has zero file length.
> > > The common denominator in the above posts and in my case, is uclibc.
> > > I upgraded from dropbear 0.48.1 to 0.50 due the the scp hang error that
...
> [pid 6696] ftruncate64(3, 51539607552) = 0
> [pid 6696] close(3) = 0
> [pid 6696] read(0, "\0", 1) = 1
> [pid 6696] write(1, "\0", 1 <unfinished ...>
> </---trace snip ---->
>
> The size parameter of the ftruncate64 call is WAY wrong!
That's certainly a bug, but how would it produce a 0 length file? (Especially
since the truncate call isn't returning an error...)
> <code>
> if (count != 0 && wrerr == NO &&
> atomicio(vwrite, ofd, bp->buf, count) != count) {
> wrerr = YES;
> wrerrno = errno;
> }
>
> if (wrerr == NO && ftruncate(ofd, size) != 0) {
> run_err("%s: truncate: %s", np, strerror(errno));
> wrerr = DISPLAYED;
> }
> </code>
> This code has not change in a while. I also verified the 'size' has the
> correct value just before the ftruncate.
Why is uClibc calling ftruncate64() for this on gumstix? Is that a 64 bit
processor, or does it have large file support? This sounds like a uClibc
issue. What version of uClibc are you using?
In any case, uClibc should be casting size to uint64_t inside the call to
ftruncate. Sounds like a mismatch between the prototype and the actual
syscall...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
