> I think you'll find that most distro makers and most vendors of Linux > based devices will want to have this patch applied. So if we took the Good for them > approach you suggest, then the testing done via kernel.org trees will > not match what the vast majority of Linux users will actually be > running. That would seem to be counter to good QA practices. The vendor trees all contain patches and have done for years, often lots of them. They will apply the patch if you put VFAT_DUALNAMES into the kernel as well so your argument is totally bogus. It always was totally bogus, it always will be. Vendors do not use the base kernel as is in normal product. They ship Base kernel + Patches for packaging systems + .1/.2/.3 bits + Cherry pick of stuff that deals with bugs they think have to be stomped by some means + drivers they add which are not yet fit for kernel + exciting stuff they think is cool and makes their distro special (eg KMS patches) Its starting to sound like the Foundation and someone have signed some kind of settlement to get this change into the Linux kernel regardless of the technical issues, practicality or community and this is all for show anyway. > If the patch had significant negative consequences for normal use then You said yourself it can crash XP. > If we get some real examples of devices that are badly affected XP crashing by suprise if you are really really unlucky strikes me as a good example and one you provided. You've also ignored entirely the fact that this isn't a VFAT file system so irrespective of whether this goes in it should not be used for mount -o vfat. There is a clear end user expectation that vfat means "microsoft fat with extended names". By all means add support for "not vfat" but don't call it "vfat" as that is misleading an interface breakage. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
