I have a GPS that appears as a vfat USB storage device. It uses long filenames like 20090627095959.log. I had a script that reads these files and then renamed them to have .bak on the end.
Recently I disabled vfat and I've been trying to access these files via their 8.3 names, i.e. 200906~1.log. A snag is that I cannot append .bak but I don't mind instead replacing .log with .bak. Appart from this it seems to work. I am a bit nervous that because the long filenames are not being changed during the rename, something bad might happen when the GPS looks itself at the directory. So far this does not seem to have been a problem.
So I'm wondering what will happen with this new patch. Presumably I'll end up with valid long filenames but invalid 8.3 names after renaming, and I'll have to see whether the GPS minds that. My concern is that the GPS may dislike the "corrupt" entries and fail in some non-immediate way, e.g. creating corrupt files that I don't discover until much later.
I guess it comes down to which seems least likely to confuse devices like this, having no long filenames or having corrupt short filenames.
Posted Jun 27, 2009 17:57 UTC (Sat) by ncm (subscriber, #165)
[Link]
Or just turn off the patch.
A new VFAT patent avoidance patch
Posted Jun 30, 2009 1:59 UTC (Tue) by jlokier (guest, #52227)
[Link]
That will be difficult when distros adopt the patch, if he/she's not already running a custom kernel, as it's not a run-time switch. Building a custom kernel isn't hard but it's not easy either if you're not used to it.