Re: CONFIG_VFAT_FS_DUALNAMES regressions

[Martin Steigerwald]

Am Dienstag 07 Juli 2009 schrieb tridge@xxxxxxxxx:
> I've now done some experiments, and I have reproduced the problem you
> saw. I've also experimented with changing the
> vfat_build_dummy_83_buffer() to try some other combinations. I've
> found that with a simple memset(msdos_name, ' ', 11) that Win98 works
> pretty well:
>
>   http://picpaste.com/Win98-longnames.png
>
> It does show one error though. In the DOS box directory listing on the
> left notice that it shows both a long name and a short name for the
> files, with the long name being a truncated form of the short
> name. The normal commands like xcopy, notepad etc all seem to work
> fine though, so practical compatibility seems pretty good.
>
> The problem with that simple memset() approach with spaces is that it
> would cause more crashes with WinXP. It does show that there might be
> some other combination that works with both though. I'll play a bit
> more and see what I can find.
>
>  > This dualnames patch just won't fly in practice.
>
> well, "won't fly" depends on your POV I guess. Unless we're hoping
> that all the Microsoft lawyers take early retirement, I think we do
> need to have some strategy to avoiding more companies having the same
> problems that TomTom had.

Following this thread I get more and more the impression that this patch 
is playing roulette regarding compatibility with countless devices which 
use fat/vfat, with different Windows versions and with countless Windows 
applications including but not limited to low level filesystem check, 
repair and cloning tools. And I start to get the impression that it 
becomes unmanageably complex to make a clear assessment on compatibility 
in all those circumstances. Thus I can't figure how a realistic assessment 
on the impact of this patch could be made.

Have low level filesystem check, repair and cloning tools been checked 
against the patch at all?

I think the patch actively *corrupts* perfectly fine shortname FAT 
filesystems and at least for certain use scenarios even those with long 
name support.

Thus I would certainly not enable it unless forced too - already just for 
*technical* reasons. I probably would even default to compile my own 
kernel when I find that the distribution of my choice (Debian) would enable 
it.

Politically spoken I think the patch tries to workaround a problem that 
better is fixed properly and causes a precedence for other politically, 
juristically motivated patches. If the Linux kernel would be changed to 
avoid any software patent issues I am not sure whether it would even be 
able to boot anymore. As such I think the patch should not be part of 
vanilla kernels.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Attachment: signature.asc
Description: This is a digitally signed message part.