Hashbert issues and bugs
Only tested on linux.
Issue 1: Some old filesystems (notably FAT) uses DOS-time where all timestamps are interpreted as localtime (which means that a timestamp is interpreted different when you change timezone or when DST
switches). So I'd say one should not use these filesystems.
Issue 2: Some filesystems (like ntfs) allows filenames with different casing (like "Indek_bok.html" and "IndEk_bok.html"). Some others (like exFat) does not allow this. So when writing the file "Indek_bok.html" and "IndEk_bok.html" to a exFat disc, then only "IndEk_bok.html" will remain on the disc.
Issue 3: hashbert relies on the hashcodes.txt-file to be sorted by the filename alphabetically. This may become a problem ...
- ... if you use different computers like English/Swedish/German... which have different collation so they sort differently.
- ... if you begin to copy and paste rows (for example from hashcodes.txt.new.tmp to hashcodes.txt):
- then you should try to keep the order. (Otherwise the codes will be recalculated (so its no real problem (its just slower)))
Bug 1. On linux there seems to be problem with Universal_Disk_Format
. I the src-code: when using "readdir" to read an directory entry, entry->d_type should be equal to DT_DIR, but it isn't.