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.
