[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#611380: openssh-client: sftp's put -r fails with "Unable to canonicalise path"



On Thu, Jun 9, 2011 at 8:41 PM, Steven Sciame <sasciame@yahoo.com> wrote:
>
>
>
>
>
>
>>________________________________
>>From: Selim T. Erdogan <selim@alumni.cs.utexas.edu>
>>To: debian-user@lists.debian.org
>>Sent: Friday, May 20, 2011 8:54 PM
>>Subject: Re: Re: Bug#611380: openssh-client: sftp's put -r fails with "Unable to canonicalise path"
>>
>>Clive Standbridge, 19.05.2011 tarihinde şöyle yazmış:
>>> > >
>>> > >  I am attempting to upload files onto my webserver using sftp.  As
>>> > >  far as I can
>>> > >  tell from reading the man pages and searching online, the correct
>>> > >  syntax once
>>> > >  connected via sftp is:
>>> > >
>>> > >  put -r *
>>> >
>>> > I'm no expert myself, but shouldn't that be
>>> >
>>> >    mput *
>>>
>>> mput doesn't seem to be an sftp command. Maybe you were thinking of
>>> lftp? But lftp's mput command doesn't appear to do recursion. lftp has
>>> a reverse mirror command "mirror -R" which looks like it will do the
>>> job. You can connect to an sftp server with lftp using a command like
>>> lftp sftp://username@host/path/to/dir
>>>
>>> Another alternative would be to use rsync e.g.
>>> rsync -aiz files username@host:/path/to/dir
>>
>>Yet another alternative might be scp instead of sftp.  I use "scp -pr"
>>often.
>>
>>
>
>
> Thank you for this.  scp works!   I really like the functionality of sftp since I can connect, search for what I want mv things around and then copy what I want.  Hopefully it will be fixed in 6.0.2? but until then thank you for scp!

While sftp and scp have uses for modest upload and downloads, both
suffer from non-specific handling of symlinks, and scp in particular
suffers from its lack of a chroot cage to isolate client access to the
server to simited areas. The result is that a recursive upload, or
download, that includes a recursive symlink can be a *disaster*. They
also suffer from confusing specifcaitons of the associated "TIMEZONE"
of uploads and downloads causing enormous confusion for international
clients, at the worst possible moments.

This sort of thing is why I've encouraged people to use WebDAV over
HTTPS, which is built into Windows network neighborhood, works well
with cadaver and ltfp for command line access, and does a better job
of publishing datestamps for the clients.


Reply to: