NetBSD Problem Report #10715
Received: (qmail 18769 invoked from network); 30 Jul 2000 23:11:34 -0000
Message-Id: <200007302311.BAA28167@danbala.tuwien.ac.at>
Date: Mon, 31 Jul 2000 01:11:12 +0200 (MEST)
From: wiz@danbala.ifoer.tuwien.ac.at
Reply-To: wiz@danbala.ifoer.tuwien.ac.at
To: gnats-bugs@gnats.netbsd.org
Subject: msdosfs LFN problems
X-Send-Pr-Version: 3.95
>Number: 10715
>Category: kern
>Synopsis: msdosfs LFN problems
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jul 30 23:12:00 +0000 2000
>Closed-Date:
>Last-Modified: Wed Aug 20 05:26:42 +0000 2014
>Originator: Thomas Klausner
>Release: 1.5C/i386 -- kernel sources from 2000/07/30
>Organization:
Thomas Klausner - wiz@danbala.tuwien.ac.at
I think...I think it's in my basement. Let me go upstairs and check.
-- M.C. Escher (1898-1972)
>Environment:
System: NetBSD danbala 1.4.2 NetBSD 1.4.2 (DANBALA) #0: Wed Jan 1 04:30:28 MET 1997 root@:/usr/src/sys/arch/i386/compile/DANBALA i386
>Description:
NetBSD sometimes creates invalid filenames on msdosfs.
>How-To-Repeat:
mount_msdos some_dos_dev /mnt
mkdir /mnt/test
touch /mnt/test/ab\ c
touch /mnt/test/\ ab\ c
touch /mnt/test/\"ab\ c
After booting to Windows, the last two files are not accessible before
running scndiskw (LFN scandisk); the first one just produces an error
for scndskw.
The first file only seems to have the problem that it contains a space
in the filename and is less than 8 characters long; the resulting LFN
must be wrong in some way (sorry, don't know how); perhaps the SFN is
wrong, instead.
I guess the problem with the second filename is that SFNs are not
allowed to start with space. One can make a file with this name in
Windows without any problems though, since it just gets a
corresponding LFN that somehow hides the problem (and the
corresponding SFN probably doesn't contain spaces at all).
And the problem with the third filename is that '"' is not allowed
in file names at all; other disallowed characters seem to include:
: * ? < | >
Of course, in SFNs, all those are disallowed, as well as
space + , ; = [ ]
I didn't look if this was checked and enforced by NetBSD.
>Fix:
Sorry, none known.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: kern-bug-people->jdolecek
Responsible-Changed-By: jdolecek
Responsible-Changed-When: Mon Jul 31 01:48:48 PDT 2000
Responsible-Changed-Why:
I'll look oon this.
From: wiz@danbala.ifoer.tuwien.ac.at
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: kern/10715: msdosfs LFN problems
Date: Mon, 31 Jul 2000 01:11:12 +0200 (MEST)
>Number: 10715
>Category: kern
>Synopsis: msdosfs LFN problems
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jul 30 16:12:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator: Thomas Klausner
>Release: 1.5C/i386 -- kernel sources from 2000/07/30
>Organization:
Thomas Klausner - wiz@danbala.tuwien.ac.at
I think...I think it's in my basement. Let me go upstairs and check.
-- M.C. Escher (1898-1972)
>Environment:
System: NetBSD danbala 1.4.2 NetBSD 1.4.2 (DANBALA) #0: Wed Jan 1 04:30:28 MET 1997 root@:/usr/src/sys/arch/i386/compile/DANBALA i386
>Description:
NetBSD sometimes creates invalid filenames on msdosfs.
>How-To-Repeat:
mount_msdos some_dos_dev /mnt
mkdir /mnt/test
touch /mnt/test/ab\ c
touch /mnt/test/\ ab\ c
touch /mnt/test/\"ab\ c
After booting to Windows, the last two files are not accessible before
running scndiskw (LFN scandisk); the first one just produces an error
for scndskw.
The first file only seems to have the problem that it contains a space
in the filename and is less than 8 characters long; the resulting LFN
must be wrong in some way (sorry, don't know how); perhaps the SFN is
wrong, instead.
I guess the problem with the second filename is that SFNs are not
allowed to start with space. One can make a file with this name in
Windows without any problems though, since it just gets a
corresponding LFN that somehow hides the problem (and the
corresponding SFN probably doesn't contain spaces at all).
And the problem with the third filename is that '"' is not allowed
in file names at all; other disallowed characters seem to include:
: * ? < | >
Of course, in SFNs, all those are disallowed, as well as
space + , ; = [ ]
I didn't look if this was checked and enforced by NetBSD.
>Fix:
Sorry, none known.
>Release-Note:
>Audit-Trail:
>Unformatted:
From: Jaromír Dolecek <jdolecek@NetBSD.org>
To: ws@NetBSD.org
Cc: wiz@danbala.ifoer.tuwien.ac.at, gnats-bugs@NetBSD.org
Subject: Re: kern/10715: msdosfs LFN problems
Date: Wed, 20 Jun 2001 23:08:09 +0200 (CEST)
--ELM993071289-1790-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Hi Wolfgang,
to solve issues outlined in kern/10715, I've come up with this patch.
Please, would you sanity check this and let me know if you see
any issues with it? Thanks.
Important changes (mainly unix2dosfn(), but also unix2dos[]):
* changes unix2dos[] to use 'X' form for <127 chars, so that the sets
could be sanity checked by human easily
* removed '+' from unix2dos[], added ' ' (space is valid SFN/LFN character,
modulo some limitations explicitly handled by code)
* when generating SFN, leading spaces are skipped properly
* the filename is explicitly checked for invalid characters, so that
they don't sneak through LFN; LFN only support +,;=[] in addition
to characters supported by SFN, nothing else
* reworked the way characters are translated from 'un' to 'dn', so that
SFN-invalid characters are properly skipped for both name and suffix;
removed bogus dp-- for if (dp) case - since dp points to the dot
and later we check un < dp, we failed to process last file name character!
* remove the bogus shortlen check, don't special case ' '
I've checked that against Microsoft specification I've downloaded from
http://209.67.75.168/download/fatgen103.pdf. Hopefully that one
is correct :)
I'm going to commit this shortly, in couple of days (after I get
confirmation from Thomas Klausner it's working for him). You'd really
help me if you'd look at it; though I think I'm doing right thing
here, an extra pair of eyes of msdosfs wizard is preferable :)
Thanks,
Jaromir
P.S. Thomas: please apply the attached patch. Please let me know
if window's scandisk/chkdsk now likes the filenames. The "\"ab\ c"
filename would be refused by NetBSD msdosfs now, so expect that.
--
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.ics.muni.cz/~dolecek/
NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!
--ELM993071289-1790-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-2
Content-Disposition: attachment; filename=lfnconv.diff
Index: msdosfs_conv.c
===================================================================
RCS file: /cvsroot/syssrc/sys/msdosfs/msdosfs_conv.c,v
retrieving revision 1.29
diff -u -p -r1.29 msdosfs_conv.c
--- msdosfs_conv.c 2001/01/18 20:28:27 1.29
+++ msdosfs_conv.c 2001/06/20 21:05:24
@@ -229,24 +229,30 @@ dos2unixtime(dd, dt, dh, tsp)
tsp->tv_nsec = (dh % 100) * 10000000;
}
+/*
+ * Characters allowed in short file names:
+ * letters, digits, characters with code value > 127 and
+ * $ % ' - _ @ ~ ` ! ( ) { } ^ # &
+ * All other characters are not allowed.
+ */
static const u_char
unix2dos[256] = {
0, 0, 0, 0, 0, 0, 0, 0, /* 00-07 */
0, 0, 0, 0, 0, 0, 0, 0, /* 08-0f */
0, 0, 0, 0, 0, 0, 0, 0, /* 10-17 */
0, 0, 0, 0, 0, 0, 0, 0, /* 18-1f */
- 0, 0x21, 0, 0x23, 0x24, 0x25, 0x26, 0x27, /* 20-27 */
- 0x28, 0x29, 0, 0x2b, 0, 0x2d, 0, 0, /* 28-2f */
- 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, /* 30-37 */
- 0x38, 0x39, 0, 0, 0, 0, 0, 0, /* 38-3f */
- 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, /* 40-47 */
- 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, /* 48-4f */
- 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, /* 50-57 */
- 0x58, 0x59, 0x5a, 0, 0, 0, 0x5e, 0x5f, /* 58-5f */
- 0x60, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, /* 60-67 */
- 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, /* 68-6f */
- 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, /* 70-77 */
- 0x58, 0x59, 0x5a, 0x7b, 0, 0x7d, 0x7e, 0, /* 78-7f */
+ ' ', '!', 0, '#', '$', '%', '&', '\'', /* 20-27 */
+ '(', ')', 0, 0, 0, '-', 0, 0, /* 28-2f */
+ '0', '1', '2', '3', '4', '5', '6', '7', /* 30-37 */
+ '8', '9', 0, 0, 0, 0, 0, 0, /* 38-3f */
+ '@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', /* 40-47 */
+ 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', /* 48-4f */
+ 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', /* 50-57 */
+ 'X', 'Y', 'Z', 0, 0, 0, '^', '_', /* 58-5f */
+ '`', 'A', 'B', 'C', 'D', 'E', 'F', 'G', /* 60-67 */
+ 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', /* 68-6f */
+ 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', /* 70-77 */
+ 'X', 'Y', 'Z', '{', 0, '}', '~', 0, /* 78-7f */
0, 0, 0, 0, 0, 0, 0, 0, /* 80-87 */
0, 0, 0, 0, 0, 0, 0, 0, /* 88-8f */
0, 0, 0, 0, 0, 0, 0, 0, /* 90-97 */
@@ -425,8 +431,7 @@ unix2dosfn(un, dn, unlen, gen)
int i, j, l;
int conv = 1;
const u_char *cp, *dp, *dp1;
- u_char gentext[6], *wcp;
- int shortlen;
+ u_char gentext[6], *wcp, ch;
/*
* Fill the dos filename string with blanks. These are DOS's pad
@@ -460,13 +465,38 @@ unix2dosfn(un, dn, unlen, gen)
return 0;
/*
+ * Skip leading blanks.
+ */
+ if (un[0] == ' ') {
+ conv = 3;
+ while(un[0] == ' ') {
+ un++;
+ unlen--;
+ }
+ }
+
+ /*
+ * Check that name contains only valid characters. If using
+ * long file names, couple additional characters are
+ * supported for them; handle them appropriately.
+ */
+ for(i=0; i < unlen; i++) {
+ ch = unix2dos[un[i]];
+ if (ch == 0) {
+ if (!strchr("+,;=[]", un[i]))
+ return (0);
+ conv = 3;
+ }
+ }
+
+ /*
* Now find the extension
* Note: dot as first char doesn't start extension
* and trailing dots and blanks are ignored
*/
- dp = dp1 = 0;
- for (cp = un + 1, i = unlen - 1; --i >= 0;) {
- switch (*cp++) {
+ dp = dp1 = NULL;
+ for (cp = un + 1, i = unlen - 1; --i >= 0; cp++) {
+ switch (*cp) {
case '.':
if (!dp1)
dp1 = cp;
@@ -474,9 +504,10 @@ unix2dosfn(un, dn, unlen, gen)
case ' ':
break;
default:
- if (dp1)
+ if (dp1) {
dp = dp1;
- dp1 = 0;
+ dp1 = NULL;
+ }
break;
}
}
@@ -489,40 +520,35 @@ unix2dosfn(un, dn, unlen, gen)
l = dp1 - dp;
else
l = unlen - (dp - un);
- for (i = 0, j = 8; i < l && j < 11; i++, j++) {
- if (dp[i] != (dn[j] = unix2dos[dp[i]])
- && conv != 3)
- conv = 2;
- if (!dn[j]) {
+ for (i = 0, j = 8; i < l && j < 11; i++) {
+ ch = unix2dos[dp[i]];
+ if (!ch) {
conv = 3;
- dn[j--] = ' ';
- }
+ continue;
+ } else if (dp[i] != ch && conv != 3)
+ conv = 2;
+
+ dn[j++] = ch;
}
if (i < l)
conv = 3;
- dp--;
} else {
for (dp = cp; *--dp == ' ' || *dp == '.';);
dp++;
}
- shortlen = (dp - un) <= 8;
-
/*
* Now convert the rest of the name
*/
- for (i = j = 0; un < dp && j < 8; i++, j++, un++) {
- if ((*un == ' ') && shortlen)
- dn[j] = ' ';
- else
- dn[j] = unix2dos[*un];
- if ((*un != dn[j])
- && conv != 3)
- conv = 2;
- if (!dn[j]) {
+ for (i = j = 0; un < dp && j < 8; i++, un++) {
+ ch = unix2dos[*un];
+ if (!ch) {
conv = 3;
- dn[j--] = ' ';
- }
+ continue;
+ } else if ((*un != ch) && conv != 3)
+ conv = 2;
+
+ dn[j++] = ch;
}
if (un < dp)
conv = 3;
--ELM993071289-1790-0_--
State-Changed-From-To: open->analyzed
State-Changed-By: jdolecek
State-Changed-When: Fri Jun 29 03:07:40 PDT 2001
State-Changed-Why:
I ~know where the problem is, currently discussing with Wolfgang correct
solution.
State-Changed-From-To: analyzed->feedback
State-Changed-By: pooka@narn.netbsd.org
State-Changed-When: Sat, 19 Jan 2008 18:51:47 +0200
State-Changed-Why:
does the patch in the PR work? it's high time we solve this as 7 years of
discussing the problem has not produced a result
From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: jdolecek@NetBSD.org, pooka@NetBSD.org
Subject: Re: kern/10715 (msdosfs LFN problems)
Date: Sat, 26 Jan 2008 15:46:43 +0100
--K8nIJk4ghYZn606h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sat, Jan 19, 2008 at 04:51:48PM +0000, Antti Kantee wrote:
> Synopsis: msdosfs LFN problems
>
> State-Changed-From-To: analyzed->feedback
> State-Changed-By: pooka@narn.netbsd.org
> State-Changed-When: Sat, 19 Jan 2008 18:51:47 +0200
> State-Changed-Why:
> does the patch in the PR work? it's high time we solve this as 7 years of
> discussing the problem has not produced a result
The patch didn't apply cleanly, I changed it to match the comment
above the list of characters.
The attached (perhaps wrongly updated) patch makes access to SFN files
on msdosfs fail, with:
ls: IMG_3098.JPG: Invalid argument
So either I updated it incorrectly, the rest of the code has changed
incompatibly in the meantime, or it is wrong :(
Thomas
--K8nIJk4ghYZn606h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="lfnconv-updated.diff"
Index: msdosfs_conv.c
===================================================================
RCS file: /cvsroot/src/sys/fs/msdosfs/msdosfs_conv.c,v
retrieving revision 1.5
diff -u -r1.5 msdosfs_conv.c
--- msdosfs_conv.c 11 Dec 2005 12:24:25 -0000 1.5
+++ msdosfs_conv.c 25 Jan 2008 16:28:53 -0000
@@ -233,6 +233,12 @@
tsp->tv_nsec = (dh % 100) * 10000000;
}
+/*
+ * Characters allowed in short file names:
+ * letters, digits, characters with code value > 127 and
+ * $ % ' - _ @ ~ ` ! ( ) { } ^ # &
+ * All other characters are not allowed.
+ */
static const u_char
unix2dos[256] = {
0, 0, 0, 0, 0, 0, 0, 0, /* 00-07 */
@@ -240,7 +246,7 @@
0, 0, 0, 0, 0, 0, 0, 0, /* 10-17 */
0, 0, 0, 0, 0, 0, 0, 0, /* 18-1f */
0, '!', 0, '#', '$', '%', '&', '\'', /* 20-27 */
- '(', ')', 0, '+', 0, '-', 0, 0, /* 28-2f */
+ '(', ')', 0, 0, 0, '-', 0, 0, /* 28-2f */
'0', '1', '2', '3', '4', '5', '6', '7', /* 30-37 */
'8', '9', 0, 0, 0, 0, 0, 0, /* 38-3f */
'@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', /* 40-47 */
@@ -429,8 +435,7 @@
int i, j, l;
int conv = 1;
const u_char *cp, *dp, *dp1;
- u_char gentext[6], *wcp;
- int shortlen;
+ u_char gentext[6], *wcp, ch;
/*
* Fill the dos filename string with blanks. These are DOS's pad
@@ -464,13 +469,38 @@
return 0;
/*
+ * Skip leading blanks.
+ */
+ if (un[0] == ' ') {
+ conv = 3;
+ while(un[0] == ' ') {
+ un++;
+ unlen--;
+ }
+ }
+
+ /*
+ * Check that name contains only valid characters. If using
+ * long file names, couple additional characters are
+ * supported for them; handle them appropriately.
+ */
+ for(i=0; i < unlen; i++) {
+ ch = unix2dos[un[i]];
+ if (ch == 0) {
+ if (!strchr("+,;=[]", un[i]))
+ return (0);
+ conv = 3;
+ }
+ }
+
+ /*
* Now find the extension
* Note: dot as first char doesn't start extension
* and trailing dots and blanks are ignored
*/
- dp = dp1 = 0;
- for (cp = un + 1, i = unlen - 1; --i >= 0;) {
- switch (*cp++) {
+ dp = dp1 = NULL;
+ for (cp = un + 1, i = unlen - 1; --i >= 0; cp++) {
+ switch (*cp) {
case '.':
if (!dp1)
dp1 = cp;
@@ -478,9 +508,10 @@
case ' ':
break;
default:
- if (dp1)
+ if (dp1) {
dp = dp1;
- dp1 = 0;
+ dp1 = NULL;
+ }
break;
}
}
@@ -493,40 +524,35 @@
l = dp1 - dp;
else
l = unlen - (dp - un);
- for (i = 0, j = 8; i < l && j < 11; i++, j++) {
- if (dp[i] != (dn[j] = unix2dos[dp[i]])
- && conv != 3)
- conv = 2;
- if (!dn[j]) {
+ for (i = 0, j = 8; i < l && j < 11; i++) {
+ ch = unix2dos[dp[i]];
+ if (!ch) {
conv = 3;
- dn[j--] = ' ';
- }
+ continue;
+ } else if (dp[i] != ch && conv != 3)
+ conv = 2;
+
+ dn[j++] = ch;
}
if (i < l)
conv = 3;
- dp--;
} else {
for (dp = cp; *--dp == ' ' || *dp == '.';);
dp++;
}
- shortlen = (dp - un) <= 8;
-
/*
* Now convert the rest of the name
*/
- for (i = j = 0; un < dp && j < 8; i++, j++, un++) {
- if ((*un == ' ') && shortlen)
- dn[j] = ' ';
- else
- dn[j] = unix2dos[*un];
- if ((*un != dn[j])
- && conv != 3)
- conv = 2;
- if (!dn[j]) {
+ for (i = j = 0; un < dp && j < 8; i++, un++) {
+ ch = unix2dos[*un];
+ if (!ch) {
conv = 3;
- dn[j--] = ' ';
- }
+ continue;
+ } else if ((*un != ch) && conv != 3)
+ conv = 2;
+
+ dn[j++] = ch;
}
if (un < dp)
conv = 3;
--K8nIJk4ghYZn606h--
State-Changed-From-To: feedback->open
State-Changed-By: wiz@narn.netbsd.org
State-Changed-When: Sat, 26 Jan 2008 14:54:10 +0000
State-Changed-Why:
Feedback supplied.
From: Antti Kantee <pooka@cs.hut.fi>
To: wiz@danbala.ifoer.tuwien.ac.at
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/10715 (msdosfs LFN problems)
Date: Sat, 26 Jan 2008 19:03:46 +0200
On Sat Jan 26 2008 at 14:50:01 +0000, Thomas Klausner wrote:
> The patch didn't apply cleanly, I changed it to match the comment
> above the list of characters.
>
> The attached (perhaps wrongly updated) patch makes access to SFN files
> on msdosfs fail, with:
> ls: IMG_3098.JPG: Invalid argument
>
> So either I updated it incorrectly, the rest of the code has changed
> incompatibly in the meantime, or it is wrong :(
What's a SFN/LFN file? I don't obviously have any on my FAT fs, since
I don't get EINVAL from ls.
If you're willing to poke around, you should easily be able to track
down where the EINVAL is coming from using rump. Here's how:
0) get a system with puffs
Å“) uncomment the "RUMP_WITHOUT_THREADS" lines from
sys/rump/librump/rump{kern,user}/Makefile both (NetBSD currently
crashes if you gdb a multithreaded program and it's quite hard to
debug anything in a crashed OS ....), rebuild
1) in sys/rump/fs/bin/msdosfs run: ./msdosfs -o dump path_to_fs /mnt
2) observe which operation returns EINVAL
3) insert breakpoint, single-step or otherwise narrow down where exactly
EINVAL is coming from
If you change msdosfs, you need to recompile fs/lib/libmsdosfs AND relink
fs/bin/msdosfs (all libs are static). Good luck ;)
--
Antti Kantee <pooka@iki.fi> Of course he runs NetBSD
http://www.iki.fi/pooka/ http://www.NetBSD.org/
"la qualité la plus indispensable du cuisinier est l'exactitude"
From: Thomas Klausner <wiz@NetBSD.org>
To: Antti Kantee <pooka@cs.hut.fi>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/10715 (msdosfs LFN problems)
Date: Sat, 26 Jan 2008 18:14:21 +0100
On Sat, Jan 26, 2008 at 07:03:46PM +0200, Antti Kantee wrote:
> What's a SFN/LFN file? I don't obviously have any on my FAT fs, since
> I don't get EINVAL from ls.
SFN is a short file name (i.e. 8.3 without any special characters).
LFN is everything else that fits on FAT32.
> If you're willing to poke around, you should easily be able to track
> down where the EINVAL is coming from using rump. Here's how:
>
> 0) get a system with puffs
> Å“) uncomment the "RUMP_WITHOUT_THREADS" lines from
> sys/rump/librump/rump{kern,user}/Makefile both (NetBSD currently
> crashes if you gdb a multithreaded program and it's quite hard to
> debug anything in a crashed OS ....), rebuild
> 1) in sys/rump/fs/bin/msdosfs run: ./msdosfs -o dump path_to_fs /mnt
> 2) observe which operation returns EINVAL
> 3) insert breakpoint, single-step or otherwise narrow down where exactly
> EINVAL is coming from
>
> If you change msdosfs, you need to recompile fs/lib/libmsdosfs AND relink
> fs/bin/msdosfs (all libs are static). Good luck ;)
Thanks :) No promises yet :)
Thomas
Responsible-Changed-From-To: jdolecek->wiz
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Sun, 15 Apr 2012 21:39:11 +0000
Responsible-Changed-Why:
mine
Responsible-Changed-From-To: wiz->kern-bug-people
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Wed, 20 Aug 2014 05:26:42 +0000
Responsible-Changed-Why:
Unblock. Haven't looked at this for two years :|
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home