Messages in this thread | | | From | OGAWA Hirofumi <> | Subject | Re: [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m. | Date | Tue, 29 Sep 2009 19:05:27 +0900 |
| |
Philippe De Muyter <phdm@macqel.be> writes:
> I have an IOMEGA home network hard disk that I can connect either by > ethernet (ftp or cifs) or by USB. because of the ftp server mode > firmware, I must keep it formatted as a vfat filesystem. > > I have copied my music files on it using the ftp mode. Using the same > ftp mode, I can also retrieve my music files without problem, and > when I list them, they have the exact names that they had on my linux > ext3 partition. > > When I connected this disk via USB, now relying on the vfat module > of linux, there were some directories that I could not reread. The > common factor of these directories names is that they end with one or > more dots, e.g. > > Simon_&_Garfunkel-Wednesday_Morning,_3_a.m. > > If I issue the `ls' or `find' command, I get this strange message : > > find: ./Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.: No such file or directory > > Adding printk's in `fat_search_long' revealed that on this disk, the > file/directory NAMES ENDING WITH DOTS ARE STORED WITH THEIR TRAILING DOTS. > > Here is a patch squetch that make accessing my > Simon_&_Garfunkel-Wednesday_Morning,_3_a.m. directory possible, but I > don't know if storing long filenames ending with dot's should not also > be fixed.
IIRC, Windows stripped the trailing ".". That filename can be read/used on Windows?
If it can be read, I think we should consider to remove vfat_striptail_len() (at least for lookup path), more investigation would be needed though.
Thanks. -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
| |