lkml.org 
[lkml]   [2009]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CONFIG_VFAT_FS_DUALNAMES regressions
On 07/21/2009 06:37 AM, tridge@samba.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


\
 
 \ /
  Last update: 2009-07-21 11:19    [from the cache]
©2003-2011 Jasper Spaans