| |||||||||||||
Workaround - read but not create long file namesWorkaround - read but not create long file namesPosted Mar 2, 2009 22:11 UTC (Mon) by tridge (guest, #26906)Parent article: Third time is the charm? I agree that we should try the approach of working around the patent. For embedded use such as in a device like the TomTom, I think it is most important for the device to be able to read long filenames on VFAT filesystems, but I don't see any need to be able to create files with long file names. On my TomTom, I don't know of any way that a user could create a file with a long file name anyway, except when the device is docked, in which case the manipulation of the VFAT filesystem is done by the host computer, not the device (it just exports a USB storage device). So this suggests a simple solution:
This argument relies on the fact that all of the claims of the VFAT patent talk about "storing" the directory entries. If you don't ever store a directory entry in the VFAT format then you can't infringe this patent. This doesn't solve the problem for all users, but it is much less drastic than dropping support for VFAT, as existing filesystems will still work. I think it would also work as a complete solution for many embedded Linux vendors. Cheers, Tridge
(Log in to post comments)
That would appear to work Posted Mar 2, 2009 22:37 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] I checked the two patents, and every single claim appears to require that something be stored; it does not appear that any claim is infringed by just reading, though it would be nice if someone with legal expertise could confirm this.It also seems that the patent is very broad, covering any possible way of encoding long names while still allowing the filesystem to look like a valid filesystem to older O/Ses that don't understand the long filename encoding (any table you could come up with would be a "second directory entry"). But this might mean it's so broad that someone has done something similar before. Any kind of database where items have both a short and a long name, and the short name has a length restriction, and you can do lookups with either name, might infringe.
That would appear to work Posted Mar 2, 2009 22:52 UTC (Mon) by jmorris42 (subscriber, #2203) [Link]
> Any kind of database where items have both a short and a long name,
> and the short name has a length restriction, and you can do lookups > with either name, might infringe.
The RockRidge extensions to ISO9660 sound like a good candidate. All of us oldtimers know RR CD-ROMS predate Win95. The question is whether the RR spec predates the patent on VFAT?
That would appear to work Posted Mar 3, 2009 16:56 UTC (Tue) by jamesh (guest, #1159) [Link]
With Rock Ridge CDs, don't you have separate name spaces for the long and short names? That is, you either use the full file names or the legacy short names, but not both.
The patent talks of a "common name space", so RR might not apply.
That would appear to work Posted Mar 5, 2009 1:14 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] With VFAT you also use either one or the other. Non-VFAT-aware systems see only the short names; VFAT-aware systems see the long names. It would appear that Rock Ridge works the same way.
That would appear to work Posted Mar 5, 2009 2:39 UTC (Thu) by jamesh (guest, #1159) [Link]
On Windows, both the long and short path names are available concurrently for VFAT. You can even mix the long and short names in a single path (e.g. "c:\Progra~1\Microsoft Office"). It really is exposed as a single name space for both types of file names.
That would appear to work Posted Mar 5, 2009 2:51 UTC (Thu) by jmorris42 (subscriber, #2203) [Link]
> It really is exposed as a single name space for both types of file names.
It is in the Windows implementation but there isn't a requirement that other implementations follow their example. I don't think the Linux vfat does, haven't used fat volumes much lately to really say. Matters not though since if doing that would work around the patent it wouldn't be a loss of usability for vfat under linux to only show/accept the long file names.
That would appear to work Posted Mar 12, 2009 9:21 UTC (Thu) by forthy (guest, #1525) [Link] RR predates VFAT, and a German court has invalidated the VFAT patent in 2007, using Rock Ridge as prior art example. See Bundespatentgericht erklärt FAT-Patent von Microsoft für nichtig (on Heise.de). Note that the patent was not only invalidated through prior art, but also did not pass the non-obviousness test. Furthermore, the patent even lacks the proper teaching. I wonder what the people at USPTO are smoking to grant patents like this. Must be some strong stuff, where they see bright new inventions on dull gray paper. The funny stuff is that on the list of these patents, the FAT patent is apparently the strongest.
UMSDOS? Posted Mar 3, 2009 4:05 UTC (Tue) by eru (subscriber, #2753) [Link] (any table you could come up with would be a "second directory entry").Doesn't the old UMSDOS extension in Linux FAT implementation then qualify as prior art? If Wikipedia is correct, it was started in 1992 and first appeared on the net in 1994 (http://en.wikipedia.org/wiki/Umsdos).
UMSDOS? Posted Mar 4, 2009 6:29 UTC (Wed) by hawk (subscriber, #3195) [Link]
Now, THAT would be something...
...If the very system they are attacking contains the prior art, and in the form of an extension for that very same file system.
Workaround - read but not create long file names Posted Mar 2, 2009 23:10 UTC (Mon) by tridge (guest, #26906) [Link] I've just realised there is a corollary to this workaround. If a embedded device vendor doesn't currently have any interface that allows the user to create files with long file names then they are not infringing the VFAT patents, even without patching the kernel to remove the code that allows long file names to be created on VFAT. This is because there is no way that anyone can demonstrate infringement of a claim about "storing" when there is no way to make the device store names in the way that is described.I think this applies to TomTom, and also to all the camera vendors and similar devices. They all create files with short file names. Many of them will happily read files that have long file names, but they tend not to have an interface to create them. In part we are saved by the common way that these devices are accessed over USB. The devices present themselves as USB storage devices, so the Linux kernel is just presenting a block interface. The creation of VFAT directory entries when done on a device that is docked is done by the host computer, not by the device, so the device vendor is off the hook. We should still consider having a kernel option that disables the creation of long file names in VFAT for all those vendors that do have an interface to creating arbitrary file names, but I think the above argument may help to reduce the impact of the VFAT patents on the embedded space quite a bit. Cheers, Tridge
Workaround - read but not create long file names Posted Mar 3, 2009 16:29 UTC (Tue) by holstein (subscriber, #6122) [Link]
This would cover embedded uses, but not desktop use, no?
|
|||||||||||||