MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

Re: SFTP MGET new restrictions



fixed

Hi Paul,
V7R1 PTF SI51208 upgrades OpenSSH to version 5.8p1. This PTF is
superseded by SI52774.
I see OpenSSH 5.8p1 when I look at the version from performing the SFTP.
But, the /QOpenSys/QIBM/UserData/SC1/OpenSSH has latest directory
openssh-4.7p1 and the etc/ssh_config from there shows the escape
character as ~. Strange.

Thanks,
Craig

Paul said:
-----------------------------------------

1) Specifically, what version of Open SSH has the issue?
2) I'm on openssh-4.7p1, which I think is current for V7R1.
3) Specifically, which PTFs were involved?


Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
craigs@xxxxxxxxx
Sent: Wednesday, August 13, 2014 11:12 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Fw: SFTP MGET new restrictions

Thanks Scott and Rob. You are right about the upgraded OpenSSH, Scott.
IBM responded that special characters must be escaped with the backslash
(\). So, I tried the following in SFTP (GET identical to MGET):
GET "*" This gets the last file and names it *
GET '*' This gets the last file and names it *
GET "\*" This threw an error about did not find the file /dir/\\\\\\*
GET "G\*" This threw an error about did not find the file /dir/G\\\\\\*
GET "~*" This threw an error about did not find the file /dir/~\\*
GET * Gets all files in /dir as we already know and keeps the same
names.
GET "File 1"* Gets the files beginning /dir/'File 1' and keeps the same
names.
GET 'File 1'* Gets the files beginning '/dir/File 1' and keeps the same
names.

So, wildcards must not be in quotes and cannot be escaped to be part of
the file name at least for the site I am testing. Why the problems with
the escape? I think in Unix, the \ is the escape but Windows is ~. This
particular site seems to be going to Windows but the ~ doesn't escape
either. Yeah, I expect file not found for the escaped character but not
those backslashes in the file name. I can make this work for now by
throwing escape characters outside quotes instead of trying to escape
them. This seems different than what IBM found on the OpenSSH website.
IBM said:
Hi Craig,
There was a discussion about this issue and I have cut and pasted a couple
of the comments below for you, but the bottom line is that you will not be
able to do the mget as you once did.

"I think the PTFs you loaded would have upgraded the version of OpenSSH
being used, and in that new version (non IBM i specific) there were
changes made to correct some issues with special characters in character
strings and how they would be interpreted. As you have discovered, they
now need to be ESCAPED using the slash character so ensure they are read
correctly.

"Pathnames and file names containing spaces are supported, however they
must be enclosed in double quotes. Since you are incorporating the
wildcard character I think it is treating it as a string literal value on
the mget command and thus attempting to run the stat() function to see if
the file "*.zip" actually exists which of course a file by this specific
name doesn't exist.

Here is some text from the sftp documentation on the OpenSSH website.

Pathnames that contain spaces must be enclosed in quotes. Any special
characters contained within pathnames that are recognized by
glob(3) must be escaped with backslashes (‘\’). "

Please let me know if this answers your question and if I can be of more
assistance.
Regards,

Patti Ryan
Software Engineer, IBMi GSC

Thanks,
Craig
----- Forwarded by Craig Strong/DEKKO on 08/13/2014 10:46 AM -----

From: Craig Strong/DEKKO
To: midrange-l@xxxxxxxxxxxx,
Date: 08/12/2014 01:34 PM
Subject: Fw: SFTP MGET new restrictions


I did more testing on the MGET "*" issue. I tried:
MGET * and got the file fine.
MGET *.txt and got the file fine.
MGET "*" and got the file renamed as *
MGET "*.txt" and got the file renamed as *.txt

So, double quotes and wildcards don't mix anymore. Anyone seen this
before?

Thanks,
Craig
----- Forwarded by Craig Strong/DEKKO on 08/12/2014 01:30 PM -----

From: Craig Strong/DEKKO
To: midrange-l@xxxxxxxxxxxx,
Date: 08/12/2014 08:55 AM
Subject: SFTP MGET new restrictions


I would be able to perform the following for years in the QSHELL SFTP:
MGET "*"
After we moved to a new system with the same O/S and same directories
including the /home directories, the MGET "*" still gets the files and
data but names them * (single asterisk). Well, for this application there
is almost always one file. The script and the O/S haven't changed. I know
there are alternatives like expect scripts and doing ls -l to an outfile
and updating the script dynamically. I would like to have this working
like before which seems to be the desired functionality. The reason for
double quotes is that I have a command that places the file to get in
double quotes and uses GET or MGET depending on if an asterisk is present.
I haven't tried MGET "*.txt" or something else yet because it is difficult
to test with the customer.
Theories: SFTP setting file somewhere using defaults after the move to the
new system. SFTP setting file authority has changed. New PTF restricting
single asterisk not being allowed in double quotes.

Any ideas how to be able to use MGET "*" and keep the same names like
before the system move?

Thanks,
Craig





Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact