Re: [lftp] Unable to Compile LFTP with OPENSSL under Debian Wheezy
lftp --version gets the openssl version from SSL_version_str variable in case it is available. Probably the version of openssl does not provide that variable. It should not affect other operations though. And BTW, on fedora 19 lftp shows openssl version correctly. 2013/11/7 Purple Nugs > I am unable to compile lftp using openssl under debian Wheezy. I have > tried all three using lftp-4.4.10 > ./configure --with-openssl=/usr > ./configure --with-openssl=/usr/lib > ./configure --with-openssl=/usr/lib/openssl > > When I make the source and do ldd i see libssl and libcrypto in the list: > linux-vdso.so.1 => (0x7fffc51fe000) > libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7f1a35814000) > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f1a355fd000) > libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 > (0x7f1a3539d000) > libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > (0x7f1a34fb9000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f1a34db1000) > libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 > (0x7f1a34b69000) > libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f1a34966000) > libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f1a3473d000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1a34538000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1a34322000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a33f98000) > /lib64/ld-linux-x86-64.so.2 (0x7f1a35a47000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f1a33d7b000) > > > However, when I do ./lftp --version I don't see OpenSSL > Libraries used: Readline 6.2, Expat 2.1.0, zlib 1.2.7 > > And when I connect to the ftp using the above strange version i see: > SSL_connect: error::lib(0):func(0):reason(0) > > > > > > > > On my other box ( running slackware 14.0 ) lftp (version 4.3.8) compiled > just fine with openssl showing ./lftp --version of: > Libraries used: Readline 5.2, Expat 2.0.1, OpenSSL 1.0.1e 11 Feb 2013 > > > > > > > Is there a trick to install lftp using OpenSSL under Debian Wheezy can not > figure it out since GnuTLS is not going to work for the ftp I need to > connect to. > > ___ > lftp mailing list > lftp@uniyar.ac.ru > http://univ.uniyar.ac.ru/mailman/listinfo/lftp > > ___ lftp mailing list lftp@uniyar.ac.ru http://univ.uniyar.ac.ru/mailman/listinfo/lftp
Re: [lftp] crash in SFtp::MergeAttrs at fi->SetUser (utf8_to_lc(a->owner));
Thank you for the report! This patch should fix the problem.
--
Alexander.
2013/11/7 Daniel Fazekas
> Recent versions of LFTP seem to crash regularly when using SFTP, always
> with a similar looking backtrace along the line of:
>
> OS X, lftp 4.4.10:
> strlen ()
> DirectedBuffer::PutTranslated (this=0x100405280, buf=0xc of bounds>) at buffer.h:179
> SFtp::utf8_to_lc (this=0x10180, s=0xc ) at
> SFtp.cc:1985
> SFtp::MergeAttrs (this=0x10180, fi=0x100700c40, a=0x1005000c0) at
> SFtp.cc:2033
> SFtp::HandleExpect (this=0x10180, e=0x100500080) at SFtp.cc:967
> SFtp::HandleReplies (this=0x10180) at SFtp.cc:1103
> SFtp::Do (this=0x10180) at SFtp.cc:95
> SMTask::Schedule () at SMTask.cc:258
> Job::WaitDone (this=0x100404080) at Job.cc:523
> Ref::operator-> () at Ref.h:569
> main (argc=1, argv=0x7fff5fbff970) at lftp.cc:570
>
> Fedora Linux 19, lftp 4.4.9:
> __strlen_sse2 () from /lib64/libc.so.6
> xstrdup(char const*, int) () from /lib64/liblftp-tasks.so.0
> StringPool::Get(char const*) () from /lib64/liblftp-tasks.so.0
> FileInfo::SetUser(char const*) () from /lib64/liblftp-tasks.so.0
> SFtp::MergeAttrs(FileInfo*, SFtp::FileAttrs const*) () from
> /usr/lib64/lftp/4.4.9/proto-sftp.so
> SFtp::HandleExpect(SFtp::Expect*) () from
> /usr/lib64/lftp/4.4.9/proto-sftp.so
> SFtp::HandleReplies() () from /usr/lib64/lftp/4.4.9/proto-sftp.so
> SFtp::Do() () from /usr/lib64/lftp/4.4.9/proto-sftp.so
> SMTask::Schedule() () from /lib64/liblftp-tasks.so.0
> Job::WaitDone() () from /lib64/liblftp-jobs.so.0
> main ()
>
> One way I'm able to reliably crash lftp almost every time is to simply
> open an sftp server, then execute as the first command:
> mget ../crash
>
> (That is, specifying a file name which does not exist. Simply "mget crash"
> usually causes a crash too, but "mget ../crash" appears to crash more
> often.)
> Very rarely, particularly if I executed other commands before, I get the
> proper "mget: Access failed: No such file" message.
>
> The crash is always ultimately caused by trying to use a->owner which
> points to a bogus buffer:
> = {buf = 0xc }, size = 4300210416,
> len = 1
>
>if(a->flags&SSH_FILEXFER_ATTR_OWNERGROUP)
>{
> fi->SetUser (utf8_to_lc(a->owner));
>
> a->flags varies between 0x500280 or 0x700180 so the
> SSH_FILEXFER_ATTR_OWNERGROUP is set.
> Yet a->owner's buf points to this bogus 0xC address while a->group is a
> normal null pointer.
>
> My client platforms are all x86_64 and the sftp servers all run OpenSSH
> 6.2p2.
>
>
> ___
> lftp mailing list
> lftp@uniyar.ac.ru
> http://univ.uniyar.ac.ru/mailman/listinfo/lftp
>
diff
Description: Binary data
___
lftp mailing list
lftp@uniyar.ac.ru
http://univ.uniyar.ac.ru/mailman/listinfo/lftp
[lftp] Unable to Compile LFTP with OPENSSL under Debian Wheezy
I am unable to compile lftp using openssl under debian Wheezy. I have tried all three using lftp-4.4.10 ./configure --with-openssl=/usr ./configure --with-openssl=/usr/lib ./configure --with-openssl=/usr/lib/openssl When I make the source and do ldd i see libssl and libcrypto in the list: linux-vdso.so.1 => (0x7fffc51fe000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7f1a35814000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f1a355fd000) libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x7f1a3539d000) libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7f1a34fb9000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f1a34db1000) libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x7f1a34b69000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f1a34966000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f1a3473d000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1a34538000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1a34322000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a33f98000) /lib64/ld-linux-x86-64.so.2 (0x7f1a35a47000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1a33d7b000) However, when I do ./lftp --version I don't see OpenSSL Libraries used: Readline 6.2, Expat 2.1.0, zlib 1.2.7 And when I connect to the ftp using the above strange version i see: SSL_connect: error::lib(0):func(0):reason(0) On my other box ( running slackware 14.0 ) lftp (version 4.3.8) compiled just fine with openssl showing ./lftp --version of: Libraries used: Readline 5.2, Expat 2.0.1, OpenSSL 1.0.1e 11 Feb 2013 Is there a trick to install lftp using OpenSSL under Debian Wheezy can not figure it out since GnuTLS is not going to work for the ftp I need to connect to. ___ lftp mailing list lftp@uniyar.ac.ru http://univ.uniyar.ac.ru/mailman/listinfo/lftp
[lftp] crash in SFtp::MergeAttrs at fi->SetUser (utf8_to_lc(a->owner));
Recent versions of LFTP seem to crash regularly when using SFTP, always with a
similar looking backtrace along the line of:
OS X, lftp 4.4.10:
strlen ()
DirectedBuffer::PutTranslated (this=0x100405280, buf=0xc ) at buffer.h:179
SFtp::utf8_to_lc (this=0x10180, s=0xc ) at
SFtp.cc:1985
SFtp::MergeAttrs (this=0x10180, fi=0x100700c40, a=0x1005000c0) at
SFtp.cc:2033
SFtp::HandleExpect (this=0x10180, e=0x100500080) at SFtp.cc:967
SFtp::HandleReplies (this=0x10180) at SFtp.cc:1103
SFtp::Do (this=0x10180) at SFtp.cc:95
SMTask::Schedule () at SMTask.cc:258
Job::WaitDone (this=0x100404080) at Job.cc:523
Ref::operator-> () at Ref.h:569
main (argc=1, argv=0x7fff5fbff970) at lftp.cc:570
Fedora Linux 19, lftp 4.4.9:
__strlen_sse2 () from /lib64/libc.so.6
xstrdup(char const*, int) () from /lib64/liblftp-tasks.so.0
StringPool::Get(char const*) () from /lib64/liblftp-tasks.so.0
FileInfo::SetUser(char const*) () from /lib64/liblftp-tasks.so.0
SFtp::MergeAttrs(FileInfo*, SFtp::FileAttrs const*) () from
/usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::HandleExpect(SFtp::Expect*) () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::HandleReplies() () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SFtp::Do() () from /usr/lib64/lftp/4.4.9/proto-sftp.so
SMTask::Schedule() () from /lib64/liblftp-tasks.so.0
Job::WaitDone() () from /lib64/liblftp-jobs.so.0
main ()
One way I'm able to reliably crash lftp almost every time is to simply open an
sftp server, then execute as the first command:
mget ../crash
(That is, specifying a file name which does not exist. Simply "mget crash"
usually causes a crash too, but "mget ../crash" appears to crash more often.)
Very rarely, particularly if I executed other commands before, I get the proper
"mget: Access failed: No such file" message.
The crash is always ultimately caused by trying to use a->owner which points to
a bogus buffer:
= {buf = 0xc }, size = 4300210416, len = 1
if(a->flags&SSH_FILEXFER_ATTR_OWNERGROUP)
{
fi->SetUser (utf8_to_lc(a->owner));
a->flags varies between 0x500280 or 0x700180 so the
SSH_FILEXFER_ATTR_OWNERGROUP is set.
Yet a->owner's buf points to this bogus 0xC address while a->group is a normal
null pointer.
My client platforms are all x86_64 and the sftp servers all run OpenSSH 6.2p2.
___
lftp mailing list
lftp@uniyar.ac.ru
http://univ.uniyar.ac.ru/mailman/listinfo/lftp
Re: [lftp] --ignore-times not always working
Thanks Alexander, I found file size compare in the mean time and discovered that for some reason the zips were getting corrupted when uploading so the file sizes were actually different in size ! This only happens rarely and I haven't been able to debug it yet. best, Rob On Nov 7, 2013, at 5:18 AM, Alexander Lukyanov wrote: > Size comparision is performed in FileInfo::SameAs. HTH. > > -- >Alexander. > > > 2013/10/24 Robert DuToit > Hi All, > > I am uploading some zipped files from OS X. > > mirror -R --ignore-time -v "/tmp/somefolder.zip" > > Some of the time the mirror works and they aren't modified since sizes > haven't changed, but about 60% of the time they are. Some files never get > modified and other do almost always. They seem mostly to be zipped folders > that get modified. > > Just wondering what lftp uses to compare sizes since the sizes are always > identical in bytes, at least viewed in Mac finder source and on server. > > I can't quite find the size compare routine in lftp source (not familiar with > C++) where I could add some logging to check what's happening there. Any > pointer'd be helpful. > > Thanks much, Rob > > > > > > > > > > ___ > lftp mailing list > lftp@uniyar.ac.ru > http://univ.uniyar.ac.ru/mailman/listinfo/lftp > ___ lftp mailing list lftp@uniyar.ac.ru http://univ.uniyar.ac.ru/mailman/listinfo/lftp
Re: [lftp] [PATCH] Fix of mirror command on lftp-4.4.10
On Tue, Oct 29, 2013 at 03:48:49PM +0900, OGAWA Hirofumi wrote: > On lftp-4.4.10, mirror command seems to have a bug. When I used mirror > command, it became very slow by like following. > > After some debugging, I noticed Http::SendArrayInfoRequest() doesn't try > to send the http request. > > When called it, mode == ARRAY_INFO && state == RECEIVING_HEADER. I think > check is wrong, and it should send the http request if state == > RECEIVING_HEADER too. Thank you! I have fixed the problem slightly differently, by setting state=CONNECTED before calling Http::SendArrayInfoRequest. -- Alexander. ___ lftp mailing list lftp@uniyar.ac.ru http://univ.uniyar.ac.ru/mailman/listinfo/lftp
