I would also have expected an error from ftruncate64 call. <br><br>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.<br>
Changing <br>
#define _FILE_OFFSET_BITS 64<br>
to<br>
#define _FILE_OFFSET_BITS 32<br>
in config.h seems to fix my problem. This forces dropbear to use the ftruncate call instead of ftruncate64 call.<br>
<br>Thanks for guiding me through the problem<br>
Jacques<br>
<br><br><br><div class="gmail_quote">On Feb 9, 2008 12:30 AM, Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Friday 08 February 2008 08:44:36 Jacques Verryn wrote:<br>> On Feb 5, 2008 11:49 PM, Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br>> > On Tuesday 05 February 2008 10:13:13 Jacques Verryn wrote:<br>
> > > The crux of the problem is if I scp a file from my desktop linux pc to<br>> > the<br>> > > gumstix, the resulting file on the gumstix has zero file length.<br>> > > The common denominator in the above posts and in my case, is uclibc.<br>
> > > I upgraded from dropbear 0.48.1 to 0.50 due the the scp hang error that<br></div>...<br><div class="Ih2E3d">> [pid 6696] ftruncate64(3, 51539607552) = 0<br>> [pid 6696] close(3) = 0<br>
> [pid 6696] read(0, "\0", 1) = 1<br>> [pid 6696] write(1, "\0", 1 <unfinished ...><br>> </---trace snip ----><br>><br>> The size parameter of the ftruncate64 call is WAY wrong!<br>
<br></div>That's certainly a bug, but how would it produce a 0 length file? (Especially<br>since the truncate call isn't returning an error...) </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class="Ih2E3d"><br>> <code><br>> if (count != 0 && wrerr == NO &&<br>> atomicio(vwrite, ofd, bp->buf, count) != count) {<br>> wrerr = YES;<br>> wrerrno = errno;<br>
> }<br>><br>> if (wrerr == NO && ftruncate(ofd, size) != 0) {<br>> run_err("%s: truncate: %s", np, strerror(errno));<br>> wrerr = DISPLAYED;<br>> }<br>
> </code><br>> This code has not change in a while. I also verified the 'size' has the<br>> correct value just before the ftruncate.<br><br></div>Why is uClibc calling ftruncate64() for this on gumstix? Is that a 64 bit<br>
processor, or does it have large file support? This sounds like a uClibc<br>issue. What version of uClibc are you using? </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>In any case, uClibc should be casting size to uint64_t inside the call to<br>ftruncate. Sounds like a mismatch between the prototype and the actual<br>syscall...<br><div><div></div><div class="Wj3C7c"><br>Rob<br>--<br>
"One of my most productive days was throwing away 1000 lines of code."<br> - Ken Thompson.<br><br><br></div></div></blockquote></div><br><br>