Re: Problems with remote repository access via sftp

Denis Corbin <[email protected]> Thu, 6 Oct 2022 23:25:27 +0200
Newsgroups gmane.comp.sysutils.backup.dar.support
Message-ID <[email protected]>
On 06/10/2022 22:22, Martin Michel wrote:
> Hi Denis,

Hi Martin,

> 
> sorry for delayed response.

no issue at all,

> 
> Concerning:
> 
>>> So it seems that dar_static can connect to my sftp but still has problems to read the archive from the given path.
>>> No problems concerning this with dar dynamically linked though.
>>>
>>>
>>> And last but not least, all versions fail to connect with SSH key method.
>>> If I use sftp directly on my cloud storage, I do not have to enter password because I configured my SSH key for authentication.
>>
>> you should add -avc command of 2.7.8.RC2 and see what libcurl reports
> 
> So I repeated the command with -avc but it gave only some summary information about my request.
> Note that here again, a slash is inserted which leads to a non-existent path on my cloud storage.
> Not shure if this is the reason for the subsequent exception.
> 
> Here is the output:
> 
> $ dar_static -avc -l sftp://[email protected]/archives/server4you/first -afile-auth
> repository parameters passed to libcurl:
>    hostname      : xxxx.your-storagebox.de
>    port          :
>    login         : xxxx
>    password      : (hidden)
>    base URL      : sftp://xxxx.your-storagebox.de/
> Asking libcurl to read directory content at sftp://xxxx.your-storagebox.de//archives/server4you/
> Final memory cleanup...
> ---- exception type = [BUG] ----------
> [source]
>          File mycurl_easyhandle_node.cpp line 176 : it seems to be a bug here
>          stack dump : [0x4f3fd9]
>          stack dump : [0x43e6e7]
>          stack dump : [0x56196a]
>          stack dump : [0x55dbb7]
>          stack dump : [0x53871e]
>          stack dump : [0x537200]
>          stack dump : [0x537760]
>          stack dump : [0x537ca2]
>          stack dump : [0x51f8ca]
>          stack dump : [0x50e957]
>          stack dump : [0x4c830b]
>          stack dump : [0x4af972]
>          stack dump : [0x4b857a]
>          stack dump : [0x48a381]
>          stack dump : [0xae5f19]
>          stack dump : [0x48c01a]
> [most outside call]
> -----------------------------------
> en
> INTERNAL ERROR, PLEASE REPORT THE PREVIOUS OUTPUT TO MAINTAINER
> 
> 
>> Thanks for this feedback, I will look forward to analyse and fix it soon.
>> But it already sounds interesting in regard to the problem we meet.
> 
> No hurry, I am working with local archives now and transfer them back and forth to my cloud storage as needed.
> Thank you for all your dedication you put into dar!


Thanks for your comprehension. I'm have quite no free time currently 
(and largely less than what I would like to have for dar an other 
software projects, I hope this to get better in a few weeks).

The bug report output you provide is purely dar/libdar's code, and yes, 
the added slash is from dar too (I just need some time to understand why 
I had added this in dar), not sure both are interdependent.

Anyway, this is high (if not at top) on my todo list for dar, unless 
some emergency/big bug arrive (in which case I will reorder my personal 
priorities), let me passing this time constrained period and I will 
address it properly.

> 
> Kind regards,
> Martin
> 

Best Regards,
Denis

>
OpenPGP_signature (application/pgp-signature, 840 B) - not displayed