Hashbert issues and bugs
Only tested on linux.
- ext4: OK
- ntfs: OK
- FAT32 / exFat: Not OK (localtime issue (see below))
- UDF on linux: Not OK (tested 2017) (seems to be a bug in linux (it might be fixed by the time you read this))
Other filesystems (filesystem / operating system combinations) haven't been tested.
Some filesystems (like FAT32 and exFat) 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
hashcodes.txt-file must be sorted
hashbert relies on the hashcodes.txt-file to be sorted by the filename alphabetically. This may become a problem ...
- ... if you use different computers with different collation (like English / Swedish / German ...) (Different collations may sort differently).
- ... if you (for what ever reason) 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)))
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. (Noted 2017 (so it might be fixed by the time you read this))