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

    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:
    > It gives details on how you can do testing without having to change
    > your kernel.
    > Cheers, Tridge
    > --


     \ /
      Last update: 2009-07-21 11:19    [W:0.024 / U:47.020 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site