Issues with Cygwin64 on Windows11

Issues with Cygwin64 on Windows11

[Dimax]

Hello.
I've never had much luck with Cygwin64 and used the 32 bit version before.
Today I have no choice and I've installed Cyg64 on my new Win11 PC.

Here is the first major issue I faced. I can not create symbolic links:

Alex@Alexo ~
$ ls /cygdrive/C/XOL/

Alex@Alexo ~
$ ln -s /cygdrive/C/XOL/ work

Alex@Alexo ~
$ ls -all work
lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/

Alex@Alexo ~
$ cd ~/work/
-bash: cd: /home/Alex/work/: No such file or directory

The link is created but I can not use it.
The only thing that I did not standard was to call installation folder
C:\Cygwin instead of default C:\Cygwin64

Any help would be highly appreciated.

Best Regards
Alex Kholodenko
XDIMAX LTD | CTO

Re: Issues with Cygwin64 on Windows11

[Takashi Yano]

On Sun, 31 Jul 2022 09:11:17 +0300
Dimax wrote:
> Hello.
> I've never had much luck with Cygwin64 and used the 32 bit version before.
> Today I have no choice and I've installed Cyg64 on my new Win11 PC.
> 
> Here is the first major issue I faced. I can not create symbolic links:
> 
> Alex@Alexo ~
> $ ls /cygdrive/C/XOL/
> 
> Alex@Alexo ~
> $ ln -s /cygdrive/C/XOL/ work
> 
> Alex@Alexo ~
> $ ls -all work
> lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/
> 
> Alex@Alexo ~
> $ cd ~/work/
> -bash: cd: /home/Alex/work/: No such file or directory
> 
> The link is created but I can not use it.
> The only thing that I did not standard was to call installation folder
> C:\Cygwin instead of default C:\Cygwin64
> 
> Any help would be highly appreciated.

Thanks for the report. This seems to happen only when
the drive letter is uppercase.

ln -s /cygdrive/c/XOL/ work
works.

Anyway, I think this is a problem of cygwin1.dll.

This
work -> /mnt/C/XOL/
should be
work -> /cygdrive/C/XOL/
shouldn't it?

It guess this is a bug in the code added for WSL
compatibility.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Issues with Cygwin64 on Windows11

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On Sun, 31 Jul 2022 17:21:32 +0900
Takashi Yano wrote:
> On Sun, 31 Jul 2022 09:11:17 +0300
> Dimax wrote:
> > Hello.
> > I've never had much luck with Cygwin64 and used the 32 bit version before.
> > Today I have no choice and I've installed Cyg64 on my new Win11 PC.
> > 
> > Here is the first major issue I faced. I can not create symbolic links:
> > 
> > Alex@Alexo ~
> > $ ls /cygdrive/C/XOL/
> > 
> > Alex@Alexo ~
> > $ ln -s /cygdrive/C/XOL/ work
> > 
> > Alex@Alexo ~
> > $ ls -all work
> > lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/
> > 
> > Alex@Alexo ~
> > $ cd ~/work/
> > -bash: cd: /home/Alex/work/: No such file or directory
> > 
> > The link is created but I can not use it.
> > The only thing that I did not standard was to call installation folder
> > C:\Cygwin instead of default C:\Cygwin64
> > 
> > Any help would be highly appreciated.
> 
> Thanks for the report. This seems to happen only when
> the drive letter is uppercase.
> 
> ln -s /cygdrive/c/XOL/ work
> works.
> 
> Anyway, I think this is a problem of cygwin1.dll.
> 
> This
> work -> /mnt/C/XOL/
> should be
> work -> /cygdrive/C/XOL/
> shouldn't it?
> 
> It guess this is a bug in the code added for WSL
> compatibility.

I found the patch attached solves the issue.

Corinna, WDYT?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: 0001-Cygwin-path-Make-some-symlinks-to-cygdrive-work.patch --]
[-- Type: text/plain, Size: 2605 bytes --]

From bb20db6a4995f5caeb269a82ab64e5cf474fab68 Mon Sep 17 00:00:00 2001
From: Takashi Yano <takashi.yano@nifty.ne.jp>
Date: Mon, 1 Aug 2022 09:02:23 +0900
Subject: [PATCH] Cygwin: path: Make some symlinks to /cygdrive/* work.

- Previously, the some symbolic links to /cygdrive/* (/cygdrive/C,
  /cygdrive/./c, /cygdrive//c, etc.) did not work. This patch fixes
  the issue.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251994.html
---
 winsup/cygwin/path.cc | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index eceafbbcf..b530ca86d 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -1916,24 +1916,40 @@ symlink_wsl (const char *oldpath, path_conv &win32_newpath)
 			  - offsetof (REPARSE_LX_SYMLINK_BUFFER,
 				      LxSymlinkReparseBuffer.PathBuffer);
   PWCHAR utf16 = tp.w_get ();
+  char *normpath = tp.c_get ();
   NTSTATUS status;
   IO_STATUS_BLOCK io;
   OBJECT_ATTRIBUTES attr;
   HANDLE fh;
   int len;
+  char *tail;
 
   rpl->ReparseTag = IO_REPARSE_TAG_LX_SYMLINK;
   rpl->Reserved = 0;
   rpl->LxSymlinkReparseBuffer.FileType = 2;
+  if (normalize_posix_path (oldpath, normpath, tail) != 0)
+    *stpncpy (normpath, oldpath, max_pathlen) = '\0';
   /* Convert cygdrive prefix to "/mnt" for WSL compatibility, but only if
      cygdrive prefix is not "/", otherwise suffer random "/mnt" symlinks... */
   if (mount_table->cygdrive_len > 1
-      && path_prefix_p (mount_table->cygdrive, oldpath,
+      && path_prefix_p (mount_table->cygdrive, normpath,
 			mount_table->cygdrive_len, false))
-    stpcpy (stpcpy (path_buf, "/mnt"),
-	    oldpath + mount_table->cygdrive_len - 1);
+    {
+      if (strlen (normpath + mount_table->cygdrive_len - 1) >= 2
+	  && (normpath[mount_table->cygdrive_len + 1] == '/'
+	      || normpath[mount_table->cygdrive_len + 1] == '\0'))
+	{
+	  char drive[] = "/x";
+	  drive[1] = tolower (normpath[mount_table->cygdrive_len]);
+	  stpcpy (stpcpy (stpcpy (path_buf, "/mnt"), drive),
+		  normpath + mount_table->cygdrive_len + 1);
+	}
+      else
+	stpcpy (stpcpy (path_buf, "/mnt"),
+		normpath + mount_table->cygdrive_len - 1);
+    }
   else
-    *stpncpy (path_buf, oldpath, max_pathlen) = '\0';
+    *stpncpy (path_buf, normpath, max_pathlen) = '\0';
   /* Convert target path to UTF-16 and then back to UTF-8 to make sure the
      WSL symlink is in UTF-8, independent of the current Cygwin codeset. */
   sys_mbstowcs (utf16, NT_MAX_PATH, path_buf);
-- 
2.37.1

Re: Issues with Cygwin64 on Windows11

[Ken Brown]

On 7/31/2022 8:23 PM, Takashi Yano wrote:
> On Sun, 31 Jul 2022 17:21:32 +0900
> Takashi Yano wrote:
>> On Sun, 31 Jul 2022 09:11:17 +0300
>> Dimax wrote:
>>> Hello.
>>> I've never had much luck with Cygwin64 and used the 32 bit version before.
>>> Today I have no choice and I've installed Cyg64 on my new Win11 PC.
>>>
>>> Here is the first major issue I faced. I can not create symbolic links:
>>>
>>> Alex@Alexo ~
>>> $ ls /cygdrive/C/XOL/
>>>
>>> Alex@Alexo ~
>>> $ ln -s /cygdrive/C/XOL/ work
>>>
>>> Alex@Alexo ~
>>> $ ls -all work
>>> lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/
>>>
>>> Alex@Alexo ~
>>> $ cd ~/work/
>>> -bash: cd: /home/Alex/work/: No such file or directory
>>>
>>> The link is created but I can not use it.
>>> The only thing that I did not standard was to call installation folder
>>> C:\Cygwin instead of default C:\Cygwin64
>>>
>>> Any help would be highly appreciated.
>>
>> Thanks for the report. This seems to happen only when
>> the drive letter is uppercase.
>>
>> ln -s /cygdrive/c/XOL/ work
>> works.
>>
>> Anyway, I think this is a problem of cygwin1.dll.
>>
>> This
>> work -> /mnt/C/XOL/
>> should be
>> work -> /cygdrive/C/XOL/
>> shouldn't it?
>>
>> It guess this is a bug in the code added for WSL
>> compatibility.
> 
> I found the patch attached solves the issue.
> 
> Corinna, WDYT?

I'm not Corinna, but replacing oldpath by normpath doesn't seem like the right 
thing to do at the time of symlink creation.  If I create a symlink under 
Cygwin, I expect the target to be used under Cygwin exactly as I enter it.  The 
internal replacement of the cygdrive prefix by /mnt for WSL compatibility is 
fine, as long as I never see it except under WSL.  But since WSL doesn't 
recognize /mnt/<uppercase drive letter>, I don't think Cygwin should convert 
/<cygdrive prefix>/<uppercase drive letter>.  Users who want WSL 
interoperability just have to use lowercase drive letters.

I'm tempted to go even further and say that Cygwin shouldn't ever convert the 
cygdrive prefix to /mnt, on the grounds that users who care about WSL 
interoperability can simply use /mnt as their cygdrive prefix.  But maybe that 
ship has sailed.

Ken

Re: Issues with Cygwin64 on Windows11

[Takashi Yano]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

On Mon, 1 Aug 2022 21:14:52 -0400
Ken Brown wrote:
> On 7/31/2022 8:23 PM, Takashi Yano wrote:
> > On Sun, 31 Jul 2022 17:21:32 +0900
> > Takashi Yano wrote:
> >> On Sun, 31 Jul 2022 09:11:17 +0300
> >> Dimax wrote:
> >>> Hello.
> >>> I've never had much luck with Cygwin64 and used the 32 bit version before.
> >>> Today I have no choice and I've installed Cyg64 on my new Win11 PC.
> >>>
> >>> Here is the first major issue I faced. I can not create symbolic links:
> >>>
> >>> Alex@Alexo ~
> >>> $ ls /cygdrive/C/XOL/
> >>>
> >>> Alex@Alexo ~
> >>> $ ln -s /cygdrive/C/XOL/ work
> >>>
> >>> Alex@Alexo ~
> >>> $ ls -all work
> >>> lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/
> >>>
> >>> Alex@Alexo ~
> >>> $ cd ~/work/
> >>> -bash: cd: /home/Alex/work/: No such file or directory
> >>>
> >>> The link is created but I can not use it.
> >>> The only thing that I did not standard was to call installation folder
> >>> C:\Cygwin instead of default C:\Cygwin64
> >>>
> >>> Any help would be highly appreciated.
> >>
> >> Thanks for the report. This seems to happen only when
> >> the drive letter is uppercase.
> >>
> >> ln -s /cygdrive/c/XOL/ work
> >> works.
> >>
> >> Anyway, I think this is a problem of cygwin1.dll.
> >>
> >> This
> >> work -> /mnt/C/XOL/
> >> should be
> >> work -> /cygdrive/C/XOL/
> >> shouldn't it?
> >>
> >> It guess this is a bug in the code added for WSL
> >> compatibility.
> > 
> > I found the patch attached solves the issue.
> > 
> > Corinna, WDYT?
> 
> I'm not Corinna, but replacing oldpath by normpath doesn't seem like the right 
> thing to do at the time of symlink creation.  If I create a symlink under 
> Cygwin, I expect the target to be used under Cygwin exactly as I enter it.  The 

Hmm, that's the point.

> internal replacement of the cygdrive prefix by /mnt for WSL compatibility is 
> fine, as long as I never see it except under WSL.  But since WSL doesn't 
> recognize /mnt/<uppercase drive letter>, I don't think Cygwin should convert 
> /<cygdrive prefix>/<uppercase drive letter>.  Users who want WSL 
> interoperability just have to use lowercase drive letters.

Then, what about the v2 patch attached?

> I'm tempted to go even further and say that Cygwin shouldn't ever convert the 
> cygdrive prefix to /mnt, on the grounds that users who care about WSL 
> interoperability can simply use /mnt as their cygdrive prefix.  But maybe that 
> ship has sailed.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

[-- Attachment #2: v2-0001-Cygwin-path-Make-some-symlinks-to-cygdrive-work.patch --]
[-- Type: text/plain, Size: 1389 bytes --]

From a190186c07449c7f9d08a13c26b87cad3f270a33 Mon Sep 17 00:00:00 2001
From: Takashi Yano <takashi.yano@nifty.ne.jp>
Date: Mon, 1 Aug 2022 09:02:23 +0900
Subject: [PATCH v2] Cygwin: path: Make some symlinks to /cygdrive/* work.

- Previously, some symbolic links to /cygdrive/* (/cygdrive/C,
  /cygdrive/./c, /cygdrive//c, etc.) did not work. This patch fixes
  the issue.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251994.html
---
 winsup/cygwin/path.cc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index eceafbbcf..c5ceb1da4 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -1929,7 +1929,11 @@ symlink_wsl (const char *oldpath, path_conv &win32_newpath)
      cygdrive prefix is not "/", otherwise suffer random "/mnt" symlinks... */
   if (mount_table->cygdrive_len > 1
       && path_prefix_p (mount_table->cygdrive, oldpath,
-			mount_table->cygdrive_len, false))
+			mount_table->cygdrive_len, false)
+      && (strlen (oldpath + mount_table->cygdrive_len - 1) < 2
+	  || (islower (oldpath[mount_table->cygdrive_len])
+	      && (oldpath[mount_table->cygdrive_len + 1] == '/'
+		  || oldpath[mount_table->cygdrive_len + 1] == '\0'))))
     stpcpy (stpcpy (path_buf, "/mnt"),
 	    oldpath + mount_table->cygdrive_len - 1);
   else
-- 
2.37.1

Re: Issues with Cygwin64 on Windows11

[Corinna Vinschen]

On Aug  2 13:12, Takashi Yano wrote:
> On Mon, 1 Aug 2022 21:14:52 -0400
> Ken Brown wrote:
> > On 7/31/2022 8:23 PM, Takashi Yano wrote:
> > > On Sun, 31 Jul 2022 17:21:32 +0900
> > > Takashi Yano wrote:
> > >> On Sun, 31 Jul 2022 09:11:17 +0300
> > >> Dimax wrote:
> > >>> $ ln -s /cygdrive/C/XOL/ work
> > >>> $ ls -all work
> > >>> lrwxrwxrwx 1 Alex None 11 Jul 31 09:09 work -> /mnt/C/XOL/
> > >>> $ cd ~/work/
> > >>> -bash: cd: /home/Alex/work/: No such file or directory
> > >>>
> > >> Thanks for the report. This seems to happen only when
> > >> the drive letter is uppercase.
> > >>
> > >> ln -s /cygdrive/c/XOL/ work
> > >> works.
> > >>
> > >> Anyway, I think this is a problem of cygwin1.dll.
> > >> [...]
> > > I found the patch attached solves the issue.
> > > 
> > > Corinna, WDYT?
> > 
> > I'm not Corinna, but replacing oldpath by normpath doesn't seem like
> > the right thing to do at the time of symlink creation.  If I create
> > a symlink under Cygwin, I expect the target to be used under Cygwin
> > exactly as I enter it.

Apart from the normalized mnt prefix, that's right.

> Hmm, that's the point.
> 
> > The internal replacement of the cygdrive prefix by /mnt for WSL
> > compatibility is fine, as long as I never see it except under WSL.
> > But since WSL doesn't recognize /mnt/<uppercase drive letter>, I
> > don't think Cygwin should convert /<cygdrive prefix>/<uppercase
> > drive letter>.  Users who want WSL interoperability just have to use
> > lowercase drive letters.

Yes, I agree.  I'm surprised anyway that somebody is using uppercase
drive letters voluntarily.

> Then, what about the v2 patch attached?

symlink_wsl is doing the right thing, as Ken points out.  I think, the
solution is not to change symlink creation but rather symlink
evaluation.  Locally I applied the below patch and fixed the issue:

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index ea695ed997b4..6b519d0bbe2d 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2651,7 +2651,7 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
 		}
 	      rp->ReparseDataLength = path_len + sizeof (DWORD);
 	    }
-	  else if (islower (path_buf[drv_prefix_len + 1])
+	  else if (isalpha (path_buf[drv_prefix_len + 1])
 		   && (path_len == drv_prefix_len + 2
 		       || path_buf[drv_prefix_len + 2] == '/'))
 	    {

This does not fix cases like /cygdrive/./c or something like that,
but I wonder if we really have to handle them...?

The idea was to convert /mnt into the cygdrive prefix only if this is a
cygdrive path and not to touch /mnt if it's a user generated path.

Therefore, the more effort the code makes to be clever, the higher
chances are that an incorrect conversion takes place.

Having said that, of course, we could change check_reparse_point_target
to handle multiple slashes or dot path components, kind of like the
below...

...but the point of discussion is, how much effort do we want to
put into this?

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index ea695ed997b4..c7f743b3c7bf 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2628,7 +2628,7 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
       char *path_buf = rpl->LxSymlinkReparseBuffer.PathBuffer;
       DWORD path_len = rpl->ReparseDataLength - sizeof (DWORD);
       bool full_path = false;
-      const size_t drv_prefix_len = strlen ("/mnt");
+      size_t drv_prefix_len = 4; /* strlen ("/mnt") */
       PBYTE utf16_ptr;
       PWCHAR utf16_buf;
       int utf16_bufsize;
@@ -2651,15 +2651,30 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
 		}
 	      rp->ReparseDataLength = path_len + sizeof (DWORD);
 	    }
-	  else if (islower (path_buf[drv_prefix_len + 1])
+	  else
+	    {
+	      /* Skip multiple slashes and "." path components between
+	         /mnt prefix and the drive letter. */
+	      while (true)
+		{
+		  if (path_buf[drv_prefix_len + 1] == '/')
+		    ++drv_prefix_len;
+		  else if (path_buf[drv_prefix_len + 1] == '.'
+			   && path_buf[drv_prefix_len + 2] == '/')
+		    drv_prefix_len += 2;
+		  else
+		    break;
+		}
+	      if (isalpha (path_buf[drv_prefix_len + 1])
 		   && (path_len == drv_prefix_len + 2
 		       || path_buf[drv_prefix_len + 2] == '/'))
-	    {
-	      /* Skip forward to the slash leading the drive letter.
-		 That leaves room for adding the colon. */
-	      path_buf += drv_prefix_len;
-	      path_len -= drv_prefix_len;
-	      full_path = true;
+		{
+		  /* Skip forward to the slash leading the drive letter.
+		     That leaves room for adding the colon. */
+		  path_buf += drv_prefix_len;
+		  path_len -= drv_prefix_len;
+		  full_path = true;
+		}
 	    }
 	}
       /* Compute buffer for path converted to UTF-16. */

> > I'm tempted to go even further and say that Cygwin shouldn't ever
> > convert the cygdrive prefix to /mnt, on the grounds that users who
> > care about WSL interoperability can simply use /mnt as their
> > cygdrive prefix.  But maybe that ship has sailed.

In hindsight this might have been a step too far.  I was trying to allow
interoperability and reduce the number of problems based on different
drive letter handling.  And, well, this is the first time a user has
a problem due to that :}

The ship hasn't sailed entirely.  We can revert this decision for 3.4
and just keep the /mnt conversion in check_reparse_point_target for
backward compat.  Or we just fix the problem at hand and otherwise
keep the code as is...?


Corinna

Re: Issues with Cygwin64 on Windows11

[Ken Brown]

On 8/2/2022 4:19 AM, Corinna Vinschen wrote:
> On Aug  2 13:12, Takashi Yano wrote:
>> Then, what about the v2 patch attached?
> 
> symlink_wsl is doing the right thing, as Ken points out.

Actually, I was suggesting that symlink_wsl was doing the wrong thing in case 
the user used an uppercase drive letter.  WSL doesn't recognize /mnt/C, so I 
don't think symlink_wsl should convert /cygdrive/C to /mnt/C.

> Therefore, the more effort the code makes to be clever, the higher
> chances are that an incorrect conversion takes place.

Agreed.

>>> I'm tempted to go even further and say that Cygwin shouldn't ever
>>> convert the cygdrive prefix to /mnt, on the grounds that users who
>>> care about WSL interoperability can simply use /mnt as their
>>> cygdrive prefix.  But maybe that ship has sailed.
> 
> In hindsight this might have been a step too far.  I was trying to allow
> interoperability and reduce the number of problems based on different
> drive letter handling.  And, well, this is the first time a user has
> a problem due to that :}
> 
> The ship hasn't sailed entirely.  We can revert this decision for 3.4
> and just keep the /mnt conversion in check_reparse_point_target for
> backward compat.  Or we just fix the problem at hand and otherwise
> keep the code as is...?

The latter seems like the safest solution, rather than risk breaking some other 
use case.

Ken

Re: Issues with Cygwin64 on Windows11

[Corinna Vinschen]

On Aug  2 09:57, Ken Brown wrote:
> On 8/2/2022 4:19 AM, Corinna Vinschen wrote:
> > On Aug  2 13:12, Takashi Yano wrote:
> > > Then, what about the v2 patch attached?
> > 
> > symlink_wsl is doing the right thing, as Ken points out.
> 
> Actually, I was suggesting that symlink_wsl was doing the wrong thing in
> case the user used an uppercase drive letter.  WSL doesn't recognize /mnt/C,
> so I don't think symlink_wsl should convert /cygdrive/C to /mnt/C.

Oh, ok... but then again... that means Takashi's patch is doing just the
right thing.  D'oh.  Yeah, ok, I'm fine with that.  Please feel free to
push your patch, Takashi.


Thanks,
Corinna

Re: Issues with Cygwin64 on Windows11

[Corinna Vinschen]

On Aug  2 16:36, Corinna Vinschen wrote:
> On Aug  2 09:57, Ken Brown wrote:
> > On 8/2/2022 4:19 AM, Corinna Vinschen wrote:
> > > On Aug  2 13:12, Takashi Yano wrote:
> > > > Then, what about the v2 patch attached?
> > > 
> > > symlink_wsl is doing the right thing, as Ken points out.
> > 
> > Actually, I was suggesting that symlink_wsl was doing the wrong thing in
> > case the user used an uppercase drive letter.  WSL doesn't recognize /mnt/C,
> > so I don't think symlink_wsl should convert /cygdrive/C to /mnt/C.
> 
> Oh, ok... but then again... that means Takashi's patch is doing just the
> right thing.  D'oh.  Yeah, ok, I'm fine with that.  Please feel free to
> push your patch, Takashi.

The v2 one, if that wasn't clear, sorry.


Corinna