Futilities/human/fic: Difference between revisions
(Created page with "{{fmt/title|FIC: File Index Comparator}} ==About== This is a pretty simple utility, so not a lot of options. It takes two file-tree indexes (in the format that {{l/same/lc|FTI...") |
No edit summary |
||
Line 3: | Line 3: | ||
This is a pretty simple utility, so not a lot of options. It takes two file-tree indexes (in the format that {{l/same/lc|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 is a pretty simple utility, so not a lot of options. It takes two file-tree indexes (in the format that {{l/same/lc|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 | 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. |
Revision as of 12:08, 2 September 2022
FIC: File Index Comparator
|
About
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.