Am Donnerstag 09 Juli 2009 schrieb tridge@xxxxxxxxx: > Hi Martin, Hi Tridge, > > The question before that would be whether anyone has a comprehensive > > list of those tools, cause I think there are quite many. Well at > > least those from bigger vendors should be tested I think. Paragon, > > Symantec, ... > > Do you happen to have any of those handy to test with? There might be some stuff laying around on some magazine CD/DVDs, but honestly I lack the motivation to do any testing. I am still not a fan of your patch. And I think the people that are interested in getting the patch in should do the testing - not me. Why should I do the work that TomTom and other companies not willing or able to fight patents legally might be interested in getting done? A motivation would be to think that it actually helps towards a software patent free world, but I am not convinced that it does. > > And has it been tested with Linux tools such as fsck.msdos, > > fsck.vfat, parted and partimage? I think it probably has not much > > effect on parted and partimage, but what about the fscks? > > I tested it with dosfstools (which provides the fsck.vfat on Linux > distros) and with mtools. Both required patches to work correctly. I > have submitted both patches to the maintainers of those packages. > > The patch to dosfstools makes it skip the invalid 8.3 entries, just as > windows chkdsk does. The patch is here: > > http://samba.org/tridge/dosfstools.patch1 > > The patch to mtools is partly cosmetic, and partly to fix a bug in the > VFAT checksum routine. The code in mtools incorrectly treated a nul > byte as special in 8.3 directory entries. The patch is here: > > http://samba.org/tridge/mtools.patch1 Okay. But then before activating the your Linux kernel patch as default there should a transition time to let distro pick up the newest stuff and a safety margin for users to upgrade to them. If it should be activated as default at all. > > Thus even when the patch only changes the values stored for new - or > > rewritten? - files it actively corrupts the meta consistency of the > > whole filesystem. To me it is like inserting a defective inode into > > a consistent Linux filesystem. > If the windows implementation is taken as the reference implementation > then the files are not considered defective. The windows chkdsk will > (with a small probability) complain of duplicates, but it doesn't > complain about the entries being defective in any other way. But you and others consider the characters / bytes your patch put into the short names as invalid. How did you come to that conclusion? Either these characters are invalid or they are not. An indication would be on what DOS would allow me to create. Does it allow me to create files with those characters such as blanks or null bytes with simple DOS commands. If not, then not checking filenames in short name FAT for invalid names seems to be an omission in CHKDSK for me. Even when fsck.{ext3,whatever}/xfs_check/xfs_repair doesn't moan about "/" in filenames I would still consider them invalid and think any software which creates those actively corrupts an Ext3, XFS, whatever unix filesystem. Ciao, -- 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.
