sftp "cd" command to drive letter under cygwin
Rick Patterson
rick.patterson at hotmail.com
Wed Jan 9 08:57:48 EST 2013
HI, Corinna.
> However, DOS paths are only barely supported. The right thing to do is
> NOT to use DOS paths, but the equivalent POSIX path. This is also
> documented in the User's Guide:
>
> http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32
>
I've seen that message before, and do not agree with it. Cygwin should make Windows easier for Windows developers, not harder by recommending they map all files to a different file system. Unfortunately, I think I'm about 10 years too late in this argument, and
I don't really expect Cygwin would change at this point, but I would like to point out why I think it is a less than an ideal position to have taken.
The Cygwin support for a POSIX file system is fine for those who wish or prefer to use it, and have control over all parts of their application, but to make a recommendation saying "if you don't use it you'll just get in trouble" was the wrong direction to take. A better direction would have been: "we fully support the DOS file system, but if you want to look and work like UNIX, we do that too!" How can it be a strong position to "barely support" the normal access to the native file
system of an operating system, and make it a second class citizen?
A typical application is not just all Cygwin, but has to work with other existing applications and databases, which might only normally know about "Windows" files and "UNIX" files. There's usually no support in other applications for "Windows machine but with POSIX file system".
For example: in regards to your next comment:
>There's no reason to change anything. Don't use DOS paths in Cygwin applications.
We don't have a "Cygwin" application. We have a Windows application that if you wish to use commands from a UNIX subsystem (various ones are available) then that can be accommodated. For example, sftp is a typical third-party add-on Windows application. Our application might run on a machine with no UNIX subsystem or on one with Cygwin, or one with some other UNIX utilities that include sftp.
If our application is configured to use sftp, and it sits on a Windows machine it can find "sftp" on, it assumes everything is okay, and generates a standard ftp batch transfer file, transferring windows files to other Windows and UNIX machines, using target location data fetched from a database. The database might be used by any number of applications which are not Cygwin aware, so it is natural to put pat information in this database that reflect the filesystem for the operating system of the machine, and not what what this data might be mapped to if it is used via Cygwin. What is even more complicated is now our application is supposed to know not just whether the local machine it is running on is using Cygwin, and so map local files to Cygdrive, but also whether the target machines has a Cygwin sftp on it, and if so, convert the path data written to the sftp batch files to a Cygdrive specification, suitable for the the target machine. sftp, a derivative of ftp, being one of the oldest and stradard TCP/IP applications, should not have a problem whereby it cannot find Windows files or directories when it is running on a Windows machine.
Rick
----------------------------------------
> Date: Tue, 8 Jan 2013 20:13:09 +0100
> From: vinschen at redhat.com
> To: openssh-unix-dev at mindrot.org
> Subject: Re: sftp "cd" command to drive letter under cygwin
>
> On Jan 8 18:35, Peter Stuge wrote:
> > Rick Patterson wrote:
> > > When using sftp under cygwin, a "cd d:" attempt to change to the d:
> > > drive, results in the following:
> > > sftp> cd d:/
> > > Couldn't canonicalise: No such file or directory.
> >
> > Your quote is "cd d:" but your command is "cd d:/" and those are
> > different, so the above part is not very clear. Please clarify.
> >
> >
> > > Since cygwin is supposed to support DOS paths as well as UNIX
> > > paths, and the lcd is working, I thought I'd take a look at it. I
> > > found the make_absolute function in sftp.c was assuming an absolute
> > > path starts with '/', but this is not true on Windows. I think
> > > the attached sftp.c.diff file is the fix, for your review, although
> > > there is a behavior change I'd like to discuss below.
> >
> > Why would a behavior change be acceptable? Any change that you make
> > must affect only Windows, and nothing else.
> >
> >
> > > Previously, under Cygwin, in sftp, "cd d:" would not work, unless
> > > there was a sub-directory in the current working directory that was
> > > named "d:", which is allowed on the UNIX file system, as ":" is an
> > > allowed file name character. With the proposed change, assuming
> > > you want to "cd to d:" (where d: is a drive specification, and
> > > therefore an absolute path),
> >
> > Stop right here. "d:" is *NOT* an absolute path on Windows systems.
> >
> > I'm sure you know that DOS and Windows both keep track of the current
> > working directory per drive. "d:" changes working drive, but does NOT
> > change current working directory either on the current driver or on d:.
>
>
> > "d:\" and "d:/" are absolute paths.
>
> This isn't correct. Cygwin doesn't follow the lead of the CMD shell
> here. As a POSIX layer it only keeps track of a single CWD, in POSIX
> and native NT notation. Therefore, on Cygwin, d: is an absolute path,
> too.
>
> However, DOS paths are only barely supported. The right thing to do is
> NOT to use DOS paths, but the equivalent POSIX path. This is also
> documented in the User's Guide:
>
> http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32
>
> > I'd suggest to look at the Cygwin source code to find out how exactly
> > chdir() is implemented, and to make sftp-server implement the same
> > algorithm. The client shouldn't have to be involved in this at all.
> > (Unless Cygwin patches all shells to make multiple chdir() calls, but
> > I find that somewhat unlikely.)
>
> There's no reason to change anything. Don't use DOS paths in Cygwin
> applications.
>
>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Project Co-Leader
> Red Hat
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
More information about the openssh-unix-dev
mailing list