Futilities/human/fic: Difference between revisions
< Futilities | human
Jump to navigation
Jump to search
No edit summary |
mNo edit summary |
||
| Line 6: | Line 6: | ||
This file does not have any structures that need parsing (as JSON or XML would), so it can be processed in line by line rather than having to read the entire file into memory before processing. This design decision may or may not turn out to be a good idea; the current design of FIC requires the entire list to be held in memory before outputting ''anyway'', and not preprocessing it as input means we can't estimate percentage complete -- but if that becomes important, it's easy enough switch to a read-to-memory-and-process mode. | This file does not have any structures that need parsing (as JSON or XML would), so it can be processed in line by line rather than having to read the entire file into memory before processing. This design decision may or may not turn out to be a good idea; the current design of FIC requires the entire list to be held in memory before outputting ''anyway'', and not preprocessing it as input means we can't estimate percentage complete -- but if that becomes important, it's easy enough switch to a read-to-memory-and-process mode. | ||
==History== | ==History== | ||
* '''2022-10-07''' Revising how this works -- I think what I want is: look at two file-indexes ({{l/same/lc|FTI}} output), and save (in JSON) the following: (1) hashes found in both, (2) hashes found in A but not B, (3) hashes found in B but not A. Each hash should list the filespec(s) where it was found. Since we're showing the results of a cross-comparison, it gets too complicated to | * '''2022-10-07''' Revising how this works -- I think what I want is: look at two file-indexes ({{l/same/lc|FTI}} output), and save (in JSON) the following: (1) hashes found in both, (2) hashes found in A but not B, (3) hashes found in B but not A. Each hash should list the filespec(s) where it was found. Since we're showing the results of a cross-comparison, it gets too complicated to compare more than two indexes (a feature I've not ended up using, regardless), so we'll now only allow 2 files (model and compare)... but let's change the names to A and B, since all calculations are now symmetrical. | ||
Revision as of 16:25, 7 October 2022
|
FIC: File Index Comparator
|
About
old description
This is a pretty simple utility, so not a lot of options. It takes two file-tree indexes (in the format that FTI outputs) and produces a simple text listing of all files listed in the first index that are not present in the second index.
This file does not have any structures that need parsing (as JSON or XML would), so it can be processed in line by line rather than having to read the entire file into memory before processing. This design decision may or may not turn out to be a good idea; the current design of FIC requires the entire list to be held in memory before outputting anyway, and not preprocessing it as input means we can't estimate percentage complete -- but if that becomes important, it's easy enough switch to a read-to-memory-and-process mode.
History
- 2022-10-07 Revising how this works -- I think what I want is: look at two file-indexes (FTI output), and save (in JSON) the following: (1) hashes found in both, (2) hashes found in A but not B, (3) hashes found in B but not A. Each hash should list the filespec(s) where it was found. Since we're showing the results of a cross-comparison, it gets too complicated to compare more than two indexes (a feature I've not ended up using, regardless), so we'll now only allow 2 files (model and compare)... but let's change the names to A and B, since all calculations are now symmetrical.