Re: CONFIG_VFAT_FS_DUALNAMES regressions

[Boaz Harrosh]

On 07/21/2009 06:37 AM, tridge@xxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/