similar to: scp -3 and filenames

Hi The man page says -q disables the progress meter, but it also disables all other output. $ scp -q badhost:/bin/ls . $ scp badhost:/bin/ls . ssh: badhost: Name or service not known I would like -q to disable the progress meter as documented (I don't see the point of a -q flag if all it does is discards stderr, since I can already do that with my shell), but you might prefer to update

https://bugzilla.mindrot.org/show_bug.cgi?id=1427 Summary: scp -q behavior different than documented Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: scp AssignedTo: bitbucket at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=799 Summary: scp incorrectly reports "stalled" on slow copies Product: Portable OpenSSH Version: 3.7.1p2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P4 Component: scp AssignedTo: openssh-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=2338 Bug ID: 2338 Summary: scp -3 doesn't give an error on missing source directory Product: Portable OpenSSH Version: 6.7p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: scp

http://bugzilla.mindrot.org/show_bug.cgi?id=1265 Vincent Lefevre <vincent at vinc17.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vincent at vinc17.org --- Comment #4 from Vincent Lefevre <vincent at vinc17.org> 2007-06-13 22:24:43

Hi, I have made a patch which improves scp utility. It adds two new features: rate limit and resume support. With rate limit it's possible to limit transfer speed. Resume allows to continue file transfer where it was last interrupted. Also the progress meter was improved. Here is my patch, please send comments about it and what I can do better if there is something to fix. ---

https://bugzilla.mindrot.org/show_bug.cgi?id=2701 Bug ID: 2701 Summary: sftp and scp show wrong units for speeds and file sizes in progress meter Product: Portable OpenSSH Version: 7.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

This isn't related to the snapshot, but mention of it reminded me to submit these changes. I added a few things, and made a couple small changes; here's a list of what the patch includes: - adds a "-1" argument to ssh and ssh.1 to force protocol1, similar to the existing "-2" argument. - adds "-1" and "-2" to scp and scp.1 as well. - adds

http://bugzilla.mindrot.org/show_bug.cgi?id=1265 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bitbucket at mindrot.org |djm at mindrot.org Attachment #1228| |ok?

Again, this has been lightly tested. I think there still are a few glitchs. 1. stole progressmeter() from scp.c - clean up and simplified a little to remove the 'flag' status. It now understands how to initialize itself and how to terminate itself. Along with a malloced status bar instead of the original fix width bar. 2. removed all initialization code from scp.c for progressmeter()

On Mon, 4 Nov 2019, David Newall wrote: > On 4/11/19 3:29 am, Demi M. Obenour wrote: > > I have not been able to get scp(1) to download a file with a newline > > in its name. I know that scp(1) requires that remote filenames be > > escaped for the shell, but that leads to protocol errors. > > I see something much worse: > > $ sudo sh > # echo

I've experienced some troubles using scp with remote files with spaces, amphersands or parantheses in their filenames on Linux hosts. This happens: stain at false:~$ scp "bender.linpro.no:blapp blapp" . scp: blapp: No such file or directory scp: blapp: No such file or directory stain at false:~$ scp "bender.linpro.no:blapp&blapp" . bash: blapp: command

The ability to log even just the names of the files being transferred, and possibly their sizes, has been a requested feature since early 2000 (over six years!!) and I've yet to see any of the developers on this list respond directly. I've found a patch from V?clav Tomec here: http://sweb.cz/v_t_m/ but it includes lots of other stuff (SecureID implementation and a tweak for being able to

I have not been able to get scp(1) to download a file with a newline in its name. I know that scp(1) requires that remote filenames be escaped for the shell, but that leads to protocol errors. I am also unable to get sftp(1) to handle such files. It fails with an ?unterminated quoted argument? error, no matter how I try to quote the newline. Furthermore, the SFTP CLI is not well-suited to

http://bugzilla.mindrot.org/show_bug.cgi?id=992 Summary: scp cannot handle filenames with spaces in them Product: Portable OpenSSH Version: 3.9p1 Platform: All OS/Version: All Status: NEW Keywords: patch Severity: normal Priority: P2 Component: scp AssignedTo: openssh-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=2193 Bug ID: 2193 Summary: Scp sometimes breaks non-ASCII filenames in copying progress indicator Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component: scp

On Sun, Nov 03, 2019 at 06:37:57AM -0500, Michael Lueck via samba wrote: > I have Samba shares mounted to my Linux workstation. Mostly I access files on the Samba server over the Samba mount. I use mount.cifs to bring up these mounts. > > For a couple of special cases, I use scp to transfer files between the > server and workstation. Special characters in filenames give sending them

On 03/11/2019 11:37, Michael Lueck via samba wrote: > Greetings Samba team, > > It has been a long time since I needed to ask a Samba technical question. > > Server and workstation are both running the latest Samba packages via > Ubuntu 16.04 LTS. I recently applied the security updates... actually > that was yesterday I applied them. > > >> samba

On Mon, 4 Nov 2019 at 14:07, David Newall <openssh at davidnewall.com> wrote: > [about scp] That's just awful, and I should have > thought it was not at all necessary. Am I missing something? > If you're saying that the scp protocol is an unfixable mess then the openssh team has been agreeing[0] with you for at least a decade and a half. We fix what we can, but some

I almost never use bare 'scp' or 'sftp' anymore; I start with either 'rsync' or, if 'rsync' is not present and not installable on one end or the other, the "tar-over-bare-ssh" approach: ``` tar cf - localpath | ssh remote.host 'cd remotepath && tar xvf -' ``` I'd be in favor of one of the following: 1. 'scp' goes away, and