FWKCS - Revision history

Dan Tobias: /* CSLIST1.SRT */

2016-12-10T16:45:04Z

‎CSLIST1.SRT

Dan Tobias: /* CSLIST1.SRT */

2014-06-01T18:40:09Z

‎CSLIST1.SRT

Dan Tobias at 18:37, 1 June 2014

2014-06-01T18:37:05Z

Dan Tobias at 18:32, 1 June 2014

2014-06-01T18:32:16Z

Dan Tobias: Created page with "{{FormatInfo |formattype=electronic |subcat=Filesystem |released=1989 |extensions={{ext|ndx}}, {{ext|srt}} }} '''FWKCS''' is a contents signature system for files, released by..."

2014-06-01T18:29:57Z

Created page with "{{FormatInfo |formattype=electronic |subcat=Filesystem |released=1989 |extensions={{ext|ndx}}, {{ext|srt}} }} '''FWKCS''' is a contents signature system for files, released by..."

New page

{{FormatInfo
|formattype=electronic
|subcat=Filesystem
|released=1989
|extensions={{ext|ndx}}, {{ext|srt}}
}}
'''FWKCS''' is a contents signature system for files, released by Frederick W. Kantor in 1989 and continuing in development at least through 1993. Its primary intended user was a computer bulletin board system (BBS) sysop wishing to check for duplicates among files, including ones already on the system, new ones being uploaded, and ones available through networks from other systems. By calculating hash values for each file (including compressed data within [[ZIP]] files) and checking them against stored values from previous file scans, the system could determine with a high degree of probability that a given file matched another one, without needing to compare every byte of it. This hash check is not 100% reliable, as "hash collisions" exist in which multiple different files yield the same hash value (a logical necessity given that the full data has many more bits in it than the hash, and hence many more possible values), but a well-chosen hash algorithm will rarely produce collisions in actual data.

This particular program got a bit of notoriety in the 2010s when it was cited as prior art to invalidate a group of patents regarding the use of file signature values in web platforms.

FWKCS was released for free download and installation, but users were expected to pay for a license if continuing use beyond a trial period.

== Files used ==

In addition to the various [[MS-DOS EXE|(PC/MS-DOS) executables]] and [[batch file]]s used for the program itself, FWKCS uses files with .NDX and .SRT extensions to store data on the files being checked and indexed. CSLIST.SRT has a list of file paths, alphabetically arranged, in [[ASCII]] form, one path per line. CSLIST1.SRT has filenames (without paths) and hash values, sorted by the hash. CSLIST.NDX and CSLIST1.NDX are binary files with index data.

=== CSLIST1.SRT ===

The format of CSLIST1.SRT looks like this:

<pre>
1498DE63 8902F FWKCS122.ZIPv z cs
14A1E90A 587 ACCESION.BATaFWKCS122.ZIPv
15B661D9 407 PRIVSPLT.BASaFWKCS122.ZIPv
</pre>

The hash is first, as a 8-digit hexadecimal number in columns 0-7. Then there is the file length, right justified to end at column 15. After a space, the next 12 positions contain the filename (in DOS 8+3 format), then if the file is contained within a ZIP archive that filename follows (with an 'a' preceding it and a 'v' following, apparently; various other letters are used in these positions and in the position of the archive name in entries for files not within an archive).

== Links ==
* [https://archive.org/details/cdrom-simteloctober1993 1993 shareware CD in which version 1.22 of FWKCS could be found: disc image]
* [https://archive.org/details/emcfarber_jsstestimony Testimony of Jason Scott regarding this CD]
* [https://www.google.com/patents/US7945539 One of the patents that was invalidated as a result of the testimony]
* [https://archive.org/details/539FinalDecision73 Final decision invalidating various patent claims]

@@ Line 27: / Line 27: @@
 </pre>
-The hash is first (well, a 64-bit hash... [[MD5]] is 128 bits, so it's a bit unclear what's stored here), as a 8-digit hexadecimal number in columns 0-7. Then there is the file length, right justified to end at column 15. After a space, the next 12 positions contain the filename (in DOS 8+3 format), then if the file is contained within a ZIP archive that filename follows (with an 'a' preceding it and a 'v' following, apparently; various other letters are used in these positions and in the position of the archive name in entries for files not within an archive).
+The hash is first (well, a 32-bit hash... [[MD5]] is 128 bits, so it's a bit unclear what's stored here), as a 8-digit hexadecimal number in columns 0-7. Then there is the file length, right justified to end at column 15. After a space, the next 12 positions contain the filename (in DOS 8+3 format), then if the file is contained within a ZIP archive that filename follows (with an 'a' preceding it and a 'v' following, apparently; various other letters are used in these positions and in the position of the archive name in entries for files not within an archive).
 == Links ==

← Older revision		Revision as of 18:32, 1 June 2014
Line 32:		Line 32:
	* [https://www.google.com/patents/US7945539 One of the patents that was invalidated as a result of the testimony]		* [https://www.google.com/patents/US7945539 One of the patents that was invalidated as a result of the testimony]
	* [https://archive.org/details/539FinalDecision73 Final decision invalidating various patent claims]		* [https://archive.org/details/539FinalDecision73 Final decision invalidating various patent claims]
		+
		+	[[Category:Bulletin board systems]]

@@ Line 6: / Line 6: @@
 }}
 '''FWKCS''' is a contents signature system for files, released by Frederick W. Kantor in 1989 and continuing in development at least through 1993. Its primary intended user was a computer bulletin board system (BBS) sysop wishing to check for duplicates among files, including ones already on the system, new ones being uploaded, and ones available through networks from other systems. By calculating hash values for each file (including compressed data within [[ZIP]] files) and checking them against stored values from previous file scans, the system could determine with a high degree of probability that a given file matched another one, without needing to compare every byte of it. This hash check is not 100% reliable, as "hash collisions" exist in which multiple different files yield the same hash value (a logical necessity given that the full data has many more bits in it than the hash, and hence many more possible values), but a well-chosen hash algorithm will rarely produce collisions in actual data.
 This particular program got a bit of notoriety in the 2010s when it was cited as prior art to invalidate a group of patents regarding the use of file signature values in web platforms.
@@ Line 32: / Line 34: @@
 * [https://www.google.com/patents/US7945539 One of the patents that was invalidated as a result of the testimony]
 * [https://archive.org/details/539FinalDecision73 Final decision invalidating various patent claims]
 [[Category:Bulletin board systems]]