create_missing_remote_path case sensitive on windows

[yanne]

def create_missing_remote_path(self, path):
    if path == '.':
        return
    if os.path.isabs(path):
        self.sftp_client.chdir('/')
    else:
        self.sftp_client.chdir('.')
    for dirname in path.split('/'):
        if dirname and dirname not in

self.sftp_client.listdir(self.sftp_client.getcwd()): print "INFO Creating missing remote directory '%s'" % dirname self.sftp_client.mkdir(dirname) self.sftp_client.chdir(dirname)

If I have a directory "C:\Temp" and try to copy "localfile" into "c:\temp\dir\file", I get a "bad message" error for trying to create the directory "/temp".

This is where I discovered it, but I'm sure it appears elsewhere too.

SSHLibrary really doesn't work well with Windows, the code simply has to be read once or twice while thinking about portability (or it should be declared not supporting windows). I don't know enough python to be the one to do it...

-- Aur

This issue was originally opened at Google Code on Nov 5, 2008.

[yanne]

<a href="http://code.google.com/p/robotframework-sshlibrary/issues/detail?id=6#c1>Original comment by janne.t....@gmail.com on Nov 5, 2008.

It is unfortunate that there are so many problems with the SFTP functionality on Windows SSH server.

The implementation is based on reading the SFTP protocol specification and testing agaisnt OpenSSH server on linux. We don't have a Windows SSH server available for testing.

Cna you provide me the name of the SSH server you are using, and I'll see what can be done to fix this.

Again, sorry for the trouble.

[yanne]

<a href="http://code.google.com/p/robotframework-sshlibrary/issues/detail?id=6#c3>Original comment by janne.t....@gmail.com on Nov 7, 2008.

This is taken from the SSH File Transfer Protocol Internet Draft [1]

[1] http://tools.ietf.org/id/draft-ietf-secsh-filexfer-13.txt

1. File Names

   This protocol represents file names as strings. File names are assumed to use the slash ('/') character as a directory separator.

   File names starting with a slash are "absolute", and are relative to the root of the file system. Names starting with any other character are relative to the user's default directory (home directory). Note that identifying the user is assumed to take place outside of this protocol.

   Servers SHOULD interpret a path name component ".." (Section 13) as referring to the parent directory, and "." as referring to the current directory.

   An empty path name is valid, and it refers to the user's default directory (usually the user's home directory).

   Otherwise, no syntax is defined for file names by this specification. Clients should not make any other assumptions; however, they can splice path name components returned by SSH_FXP_READDIR together using a slash ('/') as the separator, and that will work as expected.

   It is understood that the lack of well-defined semantics for file names may cause interoperability problems between clients and servers using radically different operating systems. However, this approach is known to work acceptably with most systems, and alternative approaches that e.g. treat file names as sequences of structured components are quite complicated.

   The preferred encoding for filenames is UTF-8. This is consistent with IETF Policy on Character Sets and Languages [ RFC2277 ] and it is further supposed that the server is more likely to support any local character set and be able to convert it to UTF-8.

   However, because the server does not always know the encoding of filenames, it is not always possible for the server to preform a valid translation to UTF-8. When an invalid translation to UTF-8 is preformed, it becomes impossible to manipulate the file, because the translation is not reversible. Therefore, the following extensions are provided in order to make it possible for the server to communicate it's abilities to the client, and to allow the client to control whether the server attempts the conversion.

The implementation of our library is based on this, ie. we expect that the server translates '/' characters in the path correctly to the operating system. Since we cannot know the operating system of the server, there's nothing we can do if the server decides not to respect the proposed standard. It is probably possible that we would add a keyword/initialization parameter to tell the server operating system and modify some actions based on this information. This will not be implemented in the next version however.

[yanne]

<a href="http://code.google.com/p/robotframework-sshlibrary/issues/detail?id=6#c4>Original comment by SonOfLi...@gmail.com on Nov 17, 2008.

I am using the free freeSSHd available from http://www.freesshd.com/ . I have also used OpenSSH for Windows, but gave up because of various issues unrelated to Robot.

Janne, this bug report has nothing to do with '/' vs. '\'. It is about case-sensitivity.

Can you think of a reasonable workaround?

[yanne]

<a href="http://code.google.com/p/robotframework-sshlibrary/issues/detail?id=6#c5>Original comment by pekka.klarck on Nov 17, 2008.

Noticed that the code uses os.path with remote files when it should use posixpath. Commented that in review comment for r45 .

[yanne]

<a href="http://code.google.com/p/robotframework-sshlibrary/issues/detail?id=6#c6>Original comment by janne.t....@gmail.com on Nov 19, 2008.

The code is fixed in r47

[yanne]

<a href="http://code.google.com/p/robotframework-sshlibrary/issues/detail?id=6#c7>Original comment by janne.t....@gmail.com on Nov 2, 2010.

Since most servers are case sensitive, I think it is reasonable to require case sensitivity in SSHLibrary too.