[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A65875D.7030902@panasas.com>
Date: Tue, 21 Jul 2009 12:16:13 +0300
From: Boaz Harrosh <bharrosh@...asas.com>
To: tridge@...ba.org
CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
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
On 07/21/2009 06:37 AM, tridge@...ba.org wrote:
> 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
>
I guess you tried putting a zero at first char and it breaks everybody?
> - 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.
>
I guess (35^6)*8*7 is not that bad
> - 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.
>
What if we had a user mode utility that does these short-names
renames that a user can optionally run after umount? since it
only writes the (random) short-names it's also safe.
Kind of the cop that can read and the cop that can write e-literacy
problem, No?
> 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
> --
Boaz
--
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