Dropbear 0.50 scp problem. Most probably related to uclibc

[Jacques Verryn]

I would also have expected an error from ftruncate64 call.

For some reason I was forced to compile my uClibc with large file support.
I'm not sure what that reason was since I've been tinkering with the gumstix
buildroot for about a year now.
Changing
#define _FILE_OFFSET_BITS 64
to
#define _FILE_OFFSET_BITS 32
in config.h seems to fix my problem. This forces dropbear to use the
ftruncate call instead of ftruncate64 call.

Thanks for guiding me through the problem
Jacques



On Feb 9, 2008 12:30 AM, Rob Landley <rob at landley.net> wrote:

> On Friday 08 February 2008 08:44:36 Jacques Verryn wrote:
> > On Feb 5, 2008 11:49 PM, Rob Landley <rob at landley.net> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20080211/63a5cfde/attachment.htm