Hashbert issues and bugs
Only tested on linux.
Issue 1: Some old filesystems (notebly FAT) uses DOS-time where all timestamps are interpreded 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: hashbert relies on the hashcodes.txt-file to be sorted by the filename alphabetically. Thid may become a problem if you...
- ...use different computers like English/Swedish/German... which have different collation so they sort differently.
- ...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)))
Issue 3: 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.
Bug 1. On linux there seams 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.