Hi Eric, > This hunk allowing the examination of the long name if there is not a > short name is something else entirely. > > You don't describe it in your summary, and don't make the case that > this is the correct behavior. Sorry for not explaining that part of the patch in my posting. The reason I initially included it was that during the development of this patch we were experimenting with variations of the vfat_build_dummy_83_buffer() function which put a wide varity of different values in the 11 bytes where a short filename would normally go. The most technically attractive varient was to put 11 spaces in there. That has the advantage that Windows then returns the long name to the GetShortPathName() API call, which is also what Windows does on a NTFS filesystem when the NTFS filesystem is configured not to have 8.3 names. So it would have been very nice to have this same behaviour on VFAT, instead of getting a single space back from GetShortPathName() as we get with the patch I posted. The reason we didn't go with the 11 spaces varient is that it causes WindowsXP to bluescreen. This is just a bug in WinXP, and is not present in Vista or Windows7. The 2nd technical problem with 11 spaces is that current Linux kernels would not see the long names, as the last_u logic in fat_search_long() will skip files where the the 11 bytes don't have at least one non-space byte before the first nul byte in either the 8 byte prefix or the 3 byte extension. The last_u logic is at odds with the behaviour of other operating systems for VFAT. On all windows varients that I have tested (and on MacOSX), the long name is still used no matter what values are in the 11 bytes. You can stick all nul bytes, all spaces, or anything else you like in there and Windows will still allow you to operate on the file by the long name and the filesystem will work perfectly. So that part of the patch is bringing us inline with the behaviour of other VFAT implementations. More importantly, it gives us the opportunity in the future to move to the techically better 11 spaces solution when either Microsoft fixes their WindowsXP crash bug, or WindowsXP has such a low market share that nobody cares any more (say like WfWg and maybe Win95 has now). If we don't put in this change now then we won't be able to move to the technically better solution later as we wouldn't have given Linux distros a chance to include support for the 11 spaces in distros. By putting that change in now, when (if?) we change to 11 spaces later we will not be breaking recent Linux kernels. > This should probably be split out into a separate patch if it is the > right thing to do, or drop it if (as it looks) there is no point in > that change. hopefully the above explanation makes it clear why the last_u change should go together with the vfat_build_slots() change. 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
