Message-ID: <19045.14307.658887.752950@samba.org>
Date:	Tue, 21 Jul 2009 13:37:07 +1000
From:	tridge@...ba.org
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Martin Steigerwald <Martin@...htvoll.de>,
	Jan Engelhardt <jengelh@...ozas.de>,
	Theodore Tso <tytso@....edu>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>, john.lanza@...ux.com,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, corbet@....net,
	jcm@...masters.org, torvalds@...ux-foundation.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists