From: tridge@samba.org
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Martin Steigerwald <Martin@lichtvoll.de>,
Jan Engelhardt <jengelh@medozas.de>, Theodore Tso <tytso@mit.edu>,
Rusty Russell <rusty@rustcorp.com.au>,
Pavel Machek <pavel@ucw.cz>,
john.lanza@linux.com,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
linux-fsdevel@vger.kernel.org,
Dave Kleikamp <shaggy@linux.vnet.ibm.com>,
corbet@lwn.net, jcm@jonmasters.org,
torvalds@linux-foundation.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions
Date: Tue, 21 Jul 2009 13:37:07 +1000 [thread overview]
Message-ID: <19045.14307.658887.752950@samba.org> (raw)
In-Reply-To: <87hbxhwv0j.fsf@devron.myhome.or.jp>
Thanks to everyone who helped with the testing of the previous round
of VFAT patent workaround patches.
I've posted a new set of patches today which tries to address some of
the technical problems found in the last patch.
The new patches:
- work with Win98
- work with Jan's IOneIt MP3 player
- work with all the other FAT capable devices I have available for
testing
- work with existing copies of mtools
The remaining issues that I am aware of are:
- There is a cosmetic issue with the DOS command prompt under
Win98. A directory listing works, but displays garbage in the
column where a 8.3 short filename would normally go
- Similarly, under WinXP, a "dir/x" will show garbage in the 8.3
column. For example: http://samba.org/~tridge/dir_test.png
- mtools has a similar cosmetic issue, which is fixed with a small
patch
- devices which only support 8.3 filenames will not be able to see
or use files created with long names with the patch enabled
- There is a very small chance of WinXP bluescreening if two files
in the same directory have the same 11 dummy bytes, and are
accessed in quick succession. The chances of this happening is
approximately 80x smaller than with the previous patch. As
previously noted, this is a very difficult problem to reproduce,
and in fact nobody has managed to reproduce it without modifying
the patch to use a much smaller number of random bits.
- Similarly, there is a small chance that chkdsk on Windows will
rename one file in a directory if they happen to have the same 11
byte dummy values. The probability of this happening is
approximately 80x lower than with the previous patch.
Some people have also asked that this patch change the name of the
filesystem to 'lfat' or similar. I have not included that change in
this patch as I think it is counter productive. Instead I have added a
printk_once() to produce a warning like this:
VFAT: not creating 8.3 short filenames for long names
when the first long filename is created on a VFAT filesystem with this
patch enabled.
The reason I think this is a better option than a filesystem name
change is that a name change will break a unknown number of userspace
tools, scripts and config files. For example, desktop tools for
mounting filesystems, scripts that use -t vfat, module configuration
options in /etc could all be broken without any ability to give the
user feedback on why it broke.
If you have a FAT capable device that you want to test for
compatibility with the new patches, please have a look at the
'Testing' section of the following README:
http://kernel.org/pub/linux/kernel/people/tridge/VFAT/README
It gives details on how you can do testing without having to change
your kernel.
Cheers, Tridge
next prev parent reply other threads:[~2009-07-21 3:37 UTC|newest]
Thread overview: 193+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-26 19:19 [PATCH] Added CONFIG_VFAT_FS_DUALNAMES option tridge
2009-06-26 21:40 ` H. Peter Anvin
2009-06-26 22:21 ` tridge
2009-06-27 1:48 ` OGAWA Hirofumi
2009-06-27 17:26 ` Jan Engelhardt
2009-06-27 1:56 ` OGAWA Hirofumi
2009-06-27 17:21 ` Jan Engelhardt
2009-06-28 2:59 ` tridge
2009-06-28 21:57 ` Jamie Lokier
2009-06-28 22:02 ` Jan Engelhardt
2009-06-28 22:05 ` Jamie Lokier
2009-06-29 1:23 ` tridge
2009-06-28 1:54 ` Eric W. Biederman
2009-06-28 2:19 ` tridge
2009-06-28 4:10 ` Eric W. Biederman
2009-06-28 5:38 ` tridge
2009-06-28 6:25 ` OGAWA Hirofumi
2009-06-28 19:51 ` Eric W. Biederman
2009-06-28 20:13 ` James Bottomley
2009-06-28 20:45 ` Eric W. Biederman
2009-06-28 21:45 ` James Bottomley
2009-06-28 21:28 ` tridge
2009-06-29 1:30 ` tridge
2009-06-29 22:18 ` Greg KH
2009-06-29 22:42 ` tridge
2009-06-29 22:52 ` Greg KH
2009-06-29 23:36 ` OGAWA Hirofumi
2009-06-29 23:51 ` tridge
2009-06-30 0:55 ` OGAWA Hirofumi
2009-06-30 6:31 ` Pavel Machek
2009-07-01 10:09 ` Alan Cox
2009-07-01 11:11 ` tridge
2009-07-01 11:34 ` Alan Cox
2009-07-01 10:49 ` Rusty Russell
2009-07-01 11:25 ` Alan Cox
2009-07-01 14:05 ` Theodore Tso
2009-07-01 14:17 ` Alan Cox
2009-07-02 1:42 ` tridge
2009-07-02 10:33 ` Alan Cox
2009-07-02 12:43 ` tridge
2009-07-02 21:49 ` Pavel Machek
2009-07-06 19:57 ` Jamie Lokier
2009-07-01 16:18 ` Stefan Richter
2009-07-02 23:17 ` CONFIG_VFAT_FS_DUALNAMES regression Jan Engelhardt
2009-07-02 23:37 ` tridge
2009-07-03 0:11 ` Jan Engelhardt
2009-07-03 0:25 ` tridge
2009-07-03 1:10 ` Jan Engelhardt
2009-07-03 1:26 ` tridge
2009-07-03 1:58 ` Jan Engelhardt
2009-07-11 0:14 ` Jamie Lokier
2009-07-02 23:46 ` CONFIG_VFAT_FS_DUALNAMES regressions Jan Engelhardt
2009-07-03 0:14 ` tridge
2009-07-03 0:58 ` OGAWA Hirofumi
2009-07-03 1:11 ` tridge
2009-07-03 1:50 ` Jan Engelhardt
2009-07-03 1:59 ` tridge
2009-07-03 2:09 ` Jan Engelhardt
2009-07-03 3:25 ` tridge
2009-07-03 6:46 ` OGAWA Hirofumi
2009-07-03 9:40 ` Jan Engelhardt
2009-07-03 12:24 ` tridge
2009-07-04 3:09 ` OGAWA Hirofumi
2009-07-06 11:40 ` Jan Engelhardt
2009-07-06 13:05 ` tridge
2009-07-06 16:17 ` David Newall
2009-07-06 19:33 ` Jamie Lokier
2009-07-06 18:55 ` Jan Engelhardt
2009-07-06 20:26 ` tridge
2009-07-06 20:42 ` Jan Engelhardt
2009-07-08 7:31 ` tridge
2009-07-06 20:36 ` Jan Engelhardt
2009-07-06 20:58 ` Jamie Lokier
2009-07-06 21:08 ` Jan Engelhardt
2009-07-06 22:24 ` Jamie Lokier
2009-07-07 9:36 ` Jan Engelhardt
2009-07-07 0:21 ` tridge
2009-07-07 21:56 ` Martin Steigerwald
2009-07-07 22:09 ` Martin Steigerwald
2009-07-08 3:12 ` tridge
2009-07-08 10:04 ` Alan Cox
2009-07-08 10:48 ` tridge
2009-07-08 12:02 ` Alan Cox
2009-07-08 13:02 ` tridge
2009-07-08 13:25 ` Alan Cox
2009-07-09 1:20 ` tridge
2009-07-09 9:42 ` Alan Cox
2009-07-09 13:59 ` James Bottomley
2009-07-09 14:10 ` Alan Cox
2009-07-09 15:25 ` Theodore Tso
[not found] ` <20090709171501.GA2991@infradead.org>
2009-07-09 20:57 ` David Newall
2009-07-09 22:23 ` Martin Steigerwald
2009-07-10 1:45 ` David Newall
2009-07-10 18:49 ` Martin Steigerwald
2009-07-10 19:31 ` Jonathan Corbet
2009-07-10 20:40 ` Bartlomiej Zolnierkiewicz
2009-07-12 11:21 ` Jörn Engel
2009-07-12 11:27 ` Jan Engelhardt
2009-07-13 22:20 ` Jamie Lokier
2009-07-13 22:32 ` Jan Engelhardt
2009-07-10 21:14 ` Alan Cox
2009-07-12 8:52 ` David Newall
2009-07-10 0:09 ` Alan Cox
2009-07-08 12:23 ` Jan Engelhardt
2009-07-08 15:27 ` James Bottomley
2009-07-08 15:37 ` Alan Cox
2009-07-08 16:06 ` James Bottomley
2009-07-08 16:18 ` Alan Cox
2009-07-09 4:25 ` tridge
2009-07-09 5:27 ` OGAWA Hirofumi
2009-07-09 7:21 ` Pavel Machek
2009-07-09 7:34 ` David Newall
2009-07-09 9:51 ` Alan Cox
2009-07-09 4:53 ` OGAWA Hirofumi
2009-07-09 9:53 ` Alan Cox
2009-07-12 19:39 ` OGAWA Hirofumi
2009-07-21 3:37 ` tridge [this message]
2009-07-21 9:16 ` Boaz Harrosh
2009-07-21 10:31 ` Pavel Machek
2009-07-21 13:24 ` tridge
2009-07-21 15:08 ` John Lanza
2009-07-21 19:36 ` John Lanza
2009-07-21 21:37 ` Pavel Machek
2009-07-21 22:38 ` tridge
2009-07-21 10:44 ` Jan Engelhardt
2009-07-21 13:04 ` tridge
2009-07-21 15:06 ` John Lanza
2009-07-21 19:38 ` John Lanza
2009-07-21 10:31 ` Pavel Machek
2009-07-21 13:19 ` tridge
2009-08-08 12:19 ` Pavel Machek
2009-07-08 11:39 ` Martin Steigerwald
2009-07-08 13:53 ` Jamie Lokier
2009-07-08 17:12 ` Jeremy Allison
2009-07-09 3:23 ` tridge
2009-07-09 13:34 ` Martin Steigerwald
2009-07-09 4:13 ` tridge
2009-07-09 19:47 ` Martin Steigerwald
2009-07-10 7:36 ` Pavel Machek
2009-07-10 21:12 ` Jamie Lokier
2009-07-10 21:28 ` Jamie Lokier
2009-07-11 2:03 ` Jamie Lokier
2009-07-07 19:51 ` Pavel Machek
2009-07-08 7:42 ` tridge
2009-07-08 10:27 ` Jan Engelhardt
2009-07-09 2:23 ` tridge
2009-07-09 8:24 ` Jan Engelhardt
2009-07-10 7:35 ` Pavel Machek
2009-07-06 20:04 ` Jamie Lokier
2009-07-08 7:30 ` tridge
2009-07-10 21:44 ` Jamie Lokier
2009-07-02 0:34 ` [PATCH] Added CONFIG_VFAT_FS_DUALNAMES option Rusty Russell
2009-07-02 21:46 ` Pavel Machek
2009-07-02 22:06 ` tridge
2009-07-02 22:33 ` Pavel Machek
2009-07-02 22:41 ` tridge
2009-07-02 22:44 ` Pavel Machek
2009-07-02 23:59 ` tridge
2009-07-08 9:21 ` Pavel Machek
2009-07-08 14:25 ` Paul E. McKenney
2009-07-08 21:42 ` tridge
2009-07-08 22:14 ` Paul E. McKenney
2009-07-08 23:59 ` Paul E. McKenney
2009-07-08 16:46 ` H. Peter Anvin
2009-07-03 0:03 ` Rusty Russell
2009-07-02 23:55 ` Rusty Russell
2009-07-01 10:50 ` tridge
2009-07-01 11:31 ` Alan Cox
2009-07-01 13:16 ` tridge
2009-07-01 13:38 ` Alan Cox
2009-07-01 14:02 ` tridge
2009-07-01 14:41 ` Alan Cox
2009-07-02 4:04 ` tridge
2009-07-02 10:32 ` Alan Cox
2009-07-02 12:38 ` tridge
2009-07-02 16:56 ` Alan Cox
2009-07-03 2:50 ` OGAWA Hirofumi
2009-07-02 14:56 ` James Bottomley
2009-07-02 15:27 ` Theodore Tso
2009-07-02 18:12 ` Alan Cox
2009-07-02 21:25 ` James Bottomley
2009-07-01 11:48 ` Boaz Harrosh
2009-07-01 12:28 ` tridge
2009-07-01 15:44 ` James Bottomley
2009-07-02 22:03 ` Pavel Machek
2009-07-06 20:41 ` Jamie Lokier
2009-07-07 10:02 ` Boaz Harrosh
2009-07-07 11:25 ` Jamie Lokier
2009-07-07 11:48 ` Boaz Harrosh
2009-07-07 11:50 ` tridge
2009-07-02 22:00 ` Pavel Machek
2009-07-02 22:23 ` tridge
2009-07-02 22:41 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19045.14307.658887.752950@samba.org \
--to=tridge@samba.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Martin@lichtvoll.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=corbet@lwn.net \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jcm@jonmasters.org \
--cc=jengelh@medozas.de \
--cc=john.lanza@linux.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rusty@rustcorp.com.au \
--cc=shaggy@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).