Re: [PATCH] cygwin: Trouble recognizing absolute path
On Oct 13 14:06, Gary Johnson wrote: > I thought the purpose of Cygwin was to provide a Linux-like > environment for applications, so that, for example, one could simply > recompile under Cygwin an application written for Linux and not have > to rewrite the file-handling routines to recognize DOS file names. > That's the purpose of the cygdrive directory, is it not? > > It seems to me that if "DOS paths do work, usually," it's because > the application was written to deal with them or it never looks at > any file names, but simply hands them whole to the Cygwin file I/O > API. You're right. But vim is not a Linux application. It tries hard to accomodate many non-Linux systems like OS/2, Windows, VMS, Amiga and, fwiw, any Unix flavor. DOS paths are supported in vim anyway, and even os_unix.c makes concessions to DOS paths in the OS2 case already. That's why I think adding a Cygwin case to support DOS and POSIX paths simultaneously would be ok. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [PATCH] cygwin: Trouble recognizing absolute path
On Oct 13 18:10, James Vega wrote: > On Fri, Oct 13, 2006 at 10:34:40PM +0200, Corinna Vinschen wrote: > > On Oct 13 16:06, James Vega wrote: > > > On Fri, Oct 13, 2006 at 09:38:16PM +0200, Corinna Vinschen wrote: > > > > Interesting enough it works in 6.4 without doing anything similar to my > > > > patch does to os_unix.c. What's different in swap file handling between > > > > 6.4 and 7.0 so that it works in the former but doesn;t in the latter? > > > > > > memline.c was changed for 7.0 as far as how Vim determined where to > > > store the swapfile when editing symlinks. The change was to follow the > > > symlink, find the directory the actual file was in and key off that when > > > creating the swapfile so that editing the symlink and the actual file at > > > the same time would cause the 'swapfile already exists' message. Maybe > > > this is related. The relevant code is sectioned off by '#ifdef > > > HAVE_READLINK'/'#endif' sections in memline.c > > > > Thanks for this hint. I'll look into that in the next couple of days. > > It doesn't seem to be related to the actual directory in which to place > > the swap file, though. "directory" is set to /tmp in my example, so the > > swap file should be created there. > > I misspoke slightly in my previous email. The patch isn't purely about > where to store the file. It primarily deals with determining what > actual file is being edited so that proper swapfile checking can be > performed. In order to do this it has to resolve the symlink and > determines the absolute path for the file being edited. It may be that > determining the absolute path is causing the mixup in path formats, > although that seems unlikely since it is a common function used > throughout Vim. It's about getting the correct basename, as my example shows. The path separator is slash-only in the unix case, an absolute path is one starting with / or ~, except OS2 is defined. As a result, the path C:\foo\bar is recognized as relative path. The next result is that the basename is the full path since it doesn't contain slashes. So the full path is concatenated to the swap directory, thus resulting in /tmp/C:\foo\bar. As far as I can see the culprit is the combination mch_FullName/mch_isFullName. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [PATCH] cygwin: Trouble recognizing absolute path
On Fri, Oct 13, 2006 at 10:34:40PM +0200, Corinna Vinschen wrote: > On Oct 13 16:06, James Vega wrote: > > On Fri, Oct 13, 2006 at 09:38:16PM +0200, Corinna Vinschen wrote: > > > Interesting enough it works in 6.4 without doing anything similar to my > > > patch does to os_unix.c. What's different in swap file handling between > > > 6.4 and 7.0 so that it works in the former but doesn;t in the latter? > > > > memline.c was changed for 7.0 as far as how Vim determined where to > > store the swapfile when editing symlinks. The change was to follow the > > symlink, find the directory the actual file was in and key off that when > > creating the swapfile so that editing the symlink and the actual file at > > the same time would cause the 'swapfile already exists' message. Maybe > > this is related. The relevant code is sectioned off by '#ifdef > > HAVE_READLINK'/'#endif' sections in memline.c > > Thanks for this hint. I'll look into that in the next couple of days. > It doesn't seem to be related to the actual directory in which to place > the swap file, though. "directory" is set to /tmp in my example, so the > swap file should be created there. I misspoke slightly in my previous email. The patch isn't purely about where to store the file. It primarily deals with determining what actual file is being edited so that proper swapfile checking can be performed. In order to do this it has to resolve the symlink and determines the absolute path for the file being edited. It may be that determining the absolute path is causing the mixup in path formats, although that seems unlikely since it is a common function used throughout Vim. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [PATCH] cygwin: Trouble recognizing absolute path
On 2006-10-13, Corinna Vinschen <[EMAIL PROTECTED]> wrote: > On Oct 13 21:53, Yakov Lerner wrote: > > On 10/13/06, Corinna Vinschen <[EMAIL PROTECTED]> wrote: > > >Hi, > > > > > >I got a report on the Cygwin mailing list that the following message > > >appears when trying to open /etc/hosts in vim: > > > > > > E303: Unable to open swap file for "/etc/hosts", recovery impossible > > > > > >What happens is this: > > > > > >/etc/hosts is by default a symbolic link which points to the hosts file > > >in the Windows system directory. The symbolic link is created as a link > > >to the DOS path, for instance: > > > > > > $ ls -l /etc/hosts > > > lrwxrwxrwx 1 corinna None 37 Oct 13 18:32 /etc/hosts -> > > > c:\WINDOWS\system32\drivers\etc\hosts > > > > I bet you can solve the problem by relinking /etc/hosts to > > /cygdrive/c/windows/system32/drivers/etc/hosts. > > > > This is how it *should* be linked. > > Sure, but that's not the problem. If it's not /etc/hosts it's another > symlink created by a user. DOS paths do work, usually. Hi Corinna, I thought the purpose of Cygwin was to provide a Linux-like environment for applications, so that, for example, one could simply recompile under Cygwin an application written for Linux and not have to rewrite the file-handling routines to recognize DOS file names. That's the purpose of the cygdrive directory, is it not? It seems to me that if "DOS paths do work, usually," it's because the application was written to deal with them or it never looks at any file names, but simply hands them whole to the Cygwin file I/O API. As Yakov said, it seems to me that the proper solution is for Cygwin to link /etc/hosts to /cygdrive/c/windows/system32/drivers/etc/hosts. If users have problems because they've mounted cygdrive someplace else, or have created symbolic links to DOS file names, then to quote someone on the cygwin list, WDDTT (Well Don't Do That Then). Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: [PATCH] cygwin: Trouble recognizing absolute path
On Oct 13 16:06, James Vega wrote: > On Fri, Oct 13, 2006 at 09:38:16PM +0200, Corinna Vinschen wrote: > > Interesting enough it works in 6.4 without doing anything similar to my > > patch does to os_unix.c. What's different in swap file handling between > > 6.4 and 7.0 so that it works in the former but doesn;t in the latter? > > memline.c was changed for 7.0 as far as how Vim determined where to > store the swapfile when editing symlinks. The change was to follow the > symlink, find the directory the actual file was in and key off that when > creating the swapfile so that editing the symlink and the actual file at > the same time would cause the 'swapfile already exists' message. Maybe > this is related. The relevant code is sectioned off by '#ifdef > HAVE_READLINK'/'#endif' sections in memline.c Thanks for this hint. I'll look into that in the next couple of days. It doesn't seem to be related to the actual directory in which to place the swap file, though. "directory" is set to /tmp in my example, so the swap file should be created there. And as the example shows, vim tries to do that. It just fails to extract the basename correctly from the DOS path because it doesn't treat backslashes as path separators. Btw., apparently vim doesn't use basename(3), even if the underlying system provides it. The Cygwin version of this function would return the correct basename no matter what path separators have been used. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [PATCH] cygwin: Trouble recognizing absolute path
On Oct 13 22:02, A.J.Mechelynck wrote:
> Corinna Vinschen wrote:
> >Interesting enough it works in 6.4 without doing anything similar to my
> >patch does to os_unix.c. What's different in swap file handling between
> >6.4 and 7.0 so that it works in the former but doesn;t in the latter?
>
> Is your 6.4 Vim compiled for Cygwin or for "native" W32? What is the value
> of has("win32unix") ?
Hey, you're *seriously* asking this question? :) has("win32unix") is 1
for both, vim 6.4 and 7.0. I guess I didn't install a native vim for
at least 8 years or so.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
Re: [PATCH] cygwin: Trouble recognizing absolute path
On Fri, Oct 13, 2006 at 09:38:16PM +0200, Corinna Vinschen wrote: > Interesting enough it works in 6.4 without doing anything similar to my > patch does to os_unix.c. What's different in swap file handling between > 6.4 and 7.0 so that it works in the former but doesn;t in the latter? memline.c was changed for 7.0 as far as how Vim determined where to store the swapfile when editing symlinks. The change was to follow the symlink, find the directory the actual file was in and key off that when creating the swapfile so that editing the symlink and the actual file at the same time would cause the 'swapfile already exists' message. Maybe this is related. The relevant code is sectioned off by '#ifdef HAVE_READLINK'/'#endif' sections in memline.c James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [PATCH] cygwin: Trouble recognizing absolute path
Yakov Lerner wrote: [...] I mean, I tried 'ls c:\windows' in cygwin and it does not work .. strange is it issue of version of cygwin ? I saw even weirder differences in cygwin behaviour ... fat32 vs ntfs differences... Maybe this is because \ have a special meaning for bash or some other shell you use. Try ls c:\\windows works fine for me. It is 100% off-topic on vim-dev list, so I'm sorry. Yakov
Re: [PATCH] cygwin: Trouble recognizing absolute path
On Oct 13 21:53, Yakov Lerner wrote: > On 10/13/06, Corinna Vinschen <[EMAIL PROTECTED]> wrote: > >Hi, > > > >I got a report on the Cygwin mailing list that the following message > >appears when trying to open /etc/hosts in vim: > > > > E303: Unable to open swap file for "/etc/hosts", recovery impossible > > > >What happens is this: > > > >/etc/hosts is by default a symbolic link which points to the hosts file > >in the Windows system directory. The symbolic link is created as a link > >to the DOS path, for instance: > > > > $ ls -l /etc/hosts > > lrwxrwxrwx 1 corinna None 37 Oct 13 18:32 /etc/hosts -> > > c:\WINDOWS\system32\drivers\etc\hosts > > I bet you can solve the problem by relinking /etc/hosts to > /cygdrive/c/windows/system32/drivers/etc/hosts. > > This is how it *should* be linked. Sure, but that's not the problem. If it's not /etc/hosts it's another symlink created by a user. DOS paths do work, usually. > It surprises me very much that your cygwin recognizes backslashes in > pathnames. I was under impression that cygwin does not recognize > backslashes in pathnames .. forward slashes as path separators. > I mean, I tried 'ls c:\windows' in cygwin and it does not work .. Well, this isn't a Cygwin mailing list and what you're writing is not a Cygwin problem. Backslashes still have special meaning in POSIX shells. Try ls c:\\windows or ls 'c:\windows' Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [PATCH] cygwin: Trouble recognizing absolute path
Corinna Vinschen wrote:
On Oct 13 21:33, Corinna Vinschen wrote:
On Oct 13 21:16, Bram Moolenaar wrote:
Corinna Vinschen wrote:
[...]
Below is a patch which works for me, though I'm not sure if it's
complete enough to catch all cases. There's code for OS2 in os_unix.c
which I reused, plus a new definition in mch_isFullName for the absolute
path on Cygwin.
I'd be grateful if the below or a more feasible patch which solves the
above problem, could be applied to vim.
I think this fixes only one specific problem. When Vim is compiled for
Unix it does not recognize DOS paths. And that matters in many places
(e.g., search for CASE_INSENSITIVE_FILENAME and BACKSLASH_IN_FILENAME).
Also behavior of a backslash in a file name changes. Making Vim for
Unix handle these things will be an awful lot of work...
True enough. But maybe fixing these problems as they turn up might
be a helpful approach? Anyway, what's noticable here is the fact
that this is a new problem in vim 7. It wasn't present in vim 6.4
so it is a regression.
Interesting enough it works in 6.4 without doing anything similar to my
patch does to os_unix.c. What's different in swap file handling between
6.4 and 7.0 so that it works in the former but doesn;t in the latter?
Corinna
Is your 6.4 Vim compiled for Cygwin or for "native" W32? What is the value of
has("win32unix") ?
Best regards,
Tony.
Re: [PATCH] cygwin: Trouble recognizing absolute path
On 10/13/06, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
Hi,
I got a report on the Cygwin mailing list that the following message
appears when trying to open /etc/hosts in vim:
E303: Unable to open swap file for "/etc/hosts", recovery impossible
What happens is this:
/etc/hosts is by default a symbolic link which points to the hosts file
in the Windows system directory. The symbolic link is created as a link
to the DOS path, for instance:
$ ls -l /etc/hosts
lrwxrwxrwx 1 corinna None 37 Oct 13 18:32 /etc/hosts ->
c:\WINDOWS\system32\drivers\etc\hosts
I bet you can solve the problem by relinking /etc/hosts to
/cygdrive/c/windows/system32/drivers/etc/hosts.
This is how it *should* be linked.
It surprises me very much that your cygwin recognizes backslashes in
pathnames. I was under impression that cygwin does not recognize
backslashes in pathnames .. forward slashes as path separators.
I mean, I tried 'ls c:\windows' in cygwin and it does not work ..
strange is it issue of version of cygwin ? I saw even
weirder differences in cygwin behaviour ... fat32 vs ntfs differences...
Yakov
By stracing vim I found that vim was trying to create a swap file
called "/tmp/c:\WINDOWS\system32\drivers\etc\hosts".
Cygwin is mostly treated as Unix target in vim, which is basically
correct. However, since Cygwin allows POSIX paths as well as DOS paths,
there are both types of absolute paths.
Below is a patch which works for me, though I'm not sure if it's
complete enough to catch all cases. There's code for OS2 in os_unix.c
which I reused, plus a new definition in mch_isFullName for the absolute
path on Cygwin.
I'd be grateful if the below or a more feasible patch which solves the
above problem, could be applied to vim.
Thanks in advance,
Corinna
--- os_unix.c.orig 2006-10-13 18:40:34.898586400 +0200
+++ os_unix.c 2006-10-13 19:01:44.398373000 +0200
@@ -2213,7 +2213,7 @@ mch_FullName(fname, buf, len, force)
intforce; /* also expand when already absolute
path */
{
intl;
-#ifdef OS2
+#if defined (OS2) || defined (__CYGWIN__)
intonly_drive; /* file name is only a drive letter */
#endif
#ifdef HAVE_FCHDIR
@@ -2236,7 +2236,7 @@ mch_FullName(fname, buf, len, force)
* and then do the getwd() (and get back to where we were).
* This will get the correct path name with "../" things.
*/
-#ifdef OS2
+#if defined (OS2) || defined (__CYGWIN__)
only_drive = 0;
if (((p = vim_strrchr(fname, '/')) != NULL)
|| ((p = vim_strrchr(fname, '\\')) != NULL)
@@ -2369,7 +2369,15 @@ mch_isFullName(fname)
(strchr((char *)fname,'[') && strchr((char *)fname,']'))||
(strchr((char *)fname,'<') && strchr((char *)fname,'>')) );
# else
+# ifdef __CYGWIN__
+/* POSIX and DOS paths are possible. */
+return (*fname == '/' || *fname == '~'
+ || (isalpha (fname[0]) && fname[1] == ':'
+ && (fname[2] == '/' || fname[2] == '\\'))
+ || (fname[0] == '\\' && fname[1] == '\\'));
+# else
return (*fname == '/' || *fname == '~');
+# endif
# endif
#endif
}
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
Re: [PATCH] cygwin: Trouble recognizing absolute path
On Oct 13 21:33, Corinna Vinschen wrote: > On Oct 13 21:16, Bram Moolenaar wrote: > > Corinna Vinschen wrote: > > > [...] > > > Below is a patch which works for me, though I'm not sure if it's > > > complete enough to catch all cases. There's code for OS2 in os_unix.c > > > which I reused, plus a new definition in mch_isFullName for the absolute > > > path on Cygwin. > > > > > > I'd be grateful if the below or a more feasible patch which solves the > > > above problem, could be applied to vim. > > > > I think this fixes only one specific problem. When Vim is compiled for > > Unix it does not recognize DOS paths. And that matters in many places > > (e.g., search for CASE_INSENSITIVE_FILENAME and BACKSLASH_IN_FILENAME). > > Also behavior of a backslash in a file name changes. Making Vim for > > Unix handle these things will be an awful lot of work... > > True enough. But maybe fixing these problems as they turn up might > be a helpful approach? Anyway, what's noticable here is the fact > that this is a new problem in vim 7. It wasn't present in vim 6.4 > so it is a regression. Interesting enough it works in 6.4 without doing anything similar to my patch does to os_unix.c. What's different in swap file handling between 6.4 and 7.0 so that it works in the former but doesn;t in the latter? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [PATCH] cygwin: Trouble recognizing absolute path
On Oct 13 21:16, Bram Moolenaar wrote: > Corinna Vinschen wrote: > > > I got a report on the Cygwin mailing list that the following message > > appears when trying to open /etc/hosts in vim: > > > > E303: Unable to open swap file for "/etc/hosts", recovery impossible > > > > What happens is this: > > > > /etc/hosts is by default a symbolic link which points to the hosts file > > in the Windows system directory. The symbolic link is created as a link > > to the DOS path, for instance: > > > > $ ls -l /etc/hosts > > lrwxrwxrwx 1 corinna None 37 Oct 13 18:32 /etc/hosts -> > > c:\WINDOWS\system32\drivers\etc\hosts > > > > By stracing vim I found that vim was trying to create a swap file > > called "/tmp/c:\WINDOWS\system32\drivers\etc\hosts". > > > > Cygwin is mostly treated as Unix target in vim, which is basically > > correct. However, since Cygwin allows POSIX paths as well as DOS paths, > > there are both types of absolute paths. > > > > Below is a patch which works for me, though I'm not sure if it's > > complete enough to catch all cases. There's code for OS2 in os_unix.c > > which I reused, plus a new definition in mch_isFullName for the absolute > > path on Cygwin. > > > > I'd be grateful if the below or a more feasible patch which solves the > > above problem, could be applied to vim. > > I think this fixes only one specific problem. When Vim is compiled for > Unix it does not recognize DOS paths. And that matters in many places > (e.g., search for CASE_INSENSITIVE_FILENAME and BACKSLASH_IN_FILENAME). > Also behavior of a backslash in a file name changes. Making Vim for > Unix handle these things will be an awful lot of work... True enough. But maybe fixing these problems as they turn up might be a helpful approach? Anyway, what's noticable here is the fact that this is a new problem in vim 7. It wasn't present in vim 6.4 so it is a regression. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Re: [PATCH] cygwin: Trouble recognizing absolute path
Corinna Vinschen wrote: > I got a report on the Cygwin mailing list that the following message > appears when trying to open /etc/hosts in vim: > > E303: Unable to open swap file for "/etc/hosts", recovery impossible > > What happens is this: > > /etc/hosts is by default a symbolic link which points to the hosts file > in the Windows system directory. The symbolic link is created as a link > to the DOS path, for instance: > > $ ls -l /etc/hosts > lrwxrwxrwx 1 corinna None 37 Oct 13 18:32 /etc/hosts -> > c:\WINDOWS\system32\drivers\etc\hosts > > By stracing vim I found that vim was trying to create a swap file > called "/tmp/c:\WINDOWS\system32\drivers\etc\hosts". > > Cygwin is mostly treated as Unix target in vim, which is basically > correct. However, since Cygwin allows POSIX paths as well as DOS paths, > there are both types of absolute paths. > > Below is a patch which works for me, though I'm not sure if it's > complete enough to catch all cases. There's code for OS2 in os_unix.c > which I reused, plus a new definition in mch_isFullName for the absolute > path on Cygwin. > > I'd be grateful if the below or a more feasible patch which solves the > above problem, could be applied to vim. I think this fixes only one specific problem. When Vim is compiled for Unix it does not recognize DOS paths. And that matters in many places (e.g., search for CASE_INSENSITIVE_FILENAME and BACKSLASH_IN_FILENAME). Also behavior of a backslash in a file name changes. Making Vim for Unix handle these things will be an awful lot of work... -- Micro$oft: where do you want to go today? Linux: where do you want to go tomorrow? FreeBSD: are you guys coming, or what? /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
[PATCH] cygwin: Trouble recognizing absolute path
Hi,
I got a report on the Cygwin mailing list that the following message
appears when trying to open /etc/hosts in vim:
E303: Unable to open swap file for "/etc/hosts", recovery impossible
What happens is this:
/etc/hosts is by default a symbolic link which points to the hosts file
in the Windows system directory. The symbolic link is created as a link
to the DOS path, for instance:
$ ls -l /etc/hosts
lrwxrwxrwx 1 corinna None 37 Oct 13 18:32 /etc/hosts ->
c:\WINDOWS\system32\drivers\etc\hosts
By stracing vim I found that vim was trying to create a swap file
called "/tmp/c:\WINDOWS\system32\drivers\etc\hosts".
Cygwin is mostly treated as Unix target in vim, which is basically
correct. However, since Cygwin allows POSIX paths as well as DOS paths,
there are both types of absolute paths.
Below is a patch which works for me, though I'm not sure if it's
complete enough to catch all cases. There's code for OS2 in os_unix.c
which I reused, plus a new definition in mch_isFullName for the absolute
path on Cygwin.
I'd be grateful if the below or a more feasible patch which solves the
above problem, could be applied to vim.
Thanks in advance,
Corinna
--- os_unix.c.orig 2006-10-13 18:40:34.898586400 +0200
+++ os_unix.c 2006-10-13 19:01:44.398373000 +0200
@@ -2213,7 +2213,7 @@ mch_FullName(fname, buf, len, force)
intforce; /* also expand when already absolute
path */
{
intl;
-#ifdef OS2
+#if defined (OS2) || defined (__CYGWIN__)
intonly_drive; /* file name is only a drive letter */
#endif
#ifdef HAVE_FCHDIR
@@ -2236,7 +2236,7 @@ mch_FullName(fname, buf, len, force)
* and then do the getwd() (and get back to where we were).
* This will get the correct path name with "../" things.
*/
-#ifdef OS2
+#if defined (OS2) || defined (__CYGWIN__)
only_drive = 0;
if (((p = vim_strrchr(fname, '/')) != NULL)
|| ((p = vim_strrchr(fname, '\\')) != NULL)
@@ -2369,7 +2369,15 @@ mch_isFullName(fname)
(strchr((char *)fname,'[') && strchr((char *)fname,']'))||
(strchr((char *)fname,'<') && strchr((char *)fname,'>')) );
# else
+# ifdef __CYGWIN__
+/* POSIX and DOS paths are possible. */
+return (*fname == '/' || *fname == '~'
+ || (isalpha (fname[0]) && fname[1] == ':'
+ && (fname[2] == '/' || fname[2] == '\\'))
+ || (fname[0] == '\\' && fname[1] == '\\'));
+# else
return (*fname == '/' || *fname == '~');
+# endif
# endif
#endif
}
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
