That would appear to work [LWN.net]

That would appear to work

Posted Mar 2, 2009 22:37 UTC (Mon) by JoeBuck (subscriber, #2330)
In reply to: Workaround - read but not create long file names by tridge
Parent article: Third time is the charm?

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.

(Log in to post comments)

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.