Hi Matthew, > So what's the purely technical argument for including this patch? There is no purely technical argument for including this patch, as the patch removes functionality without removing much code. However, if you are willing to concede that there are good non-technical arguments for wanting to "get the VFAT out" then choosing the best way to achieve that is most definately a technical decision, and that is what we can discuss here. Unfortunately I am unable to discuss any of the non-technical reasons for why "get the VFAT out" might be a good idea in the first place. That is damn frustrating, but it is just how things are. So, on the technical front, what we need is a patch that keeps as much functionality in Linux as possible while also giving us a high degree of confidence that the patch will make the non-technical issues go away. This patch is one way to achieve that. There are certainly other patches that would be possible, each with a different trade off in terms of functionality loss. So, from a technical point of view the patch is pretty simple. When the option is enabled you can still read all VFAT filesystems, with any filenames (long or short). If you try to create a file with a long filename then you get -1/ENAMETOOLONG. That means that Linux users running a kernel with this patch enabled can plug in VFAT formatted USB keys which have been written on windows/macosx etc systems, and see all the files. When the Linux user wants to give a file to a person running Windows, and they want to use a FAT based filesystem to do it, then the Linux user has to choose a 8.3 name for the file. That is a nuisance, but is a lot better than nothing. Cheers, Tridge -- 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
