Hashbert issues and bugs
Only tested on linux.
- ext4: OK
- ntfs: OK
- FAT32 / exFat: Not OK (localtime issue)
- 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 bin 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
Casesensitive / insensitive filenames
Some filesystems (like ntfs) allows filenames with different casing (like "myfile.txt" and "Myfile.txt"). Some others (like exFat) does not allow this. So when writing the file "myfile.txt" and "Myfile.txt" to a exFat disc, then only "Myfile.txt" will remain on the disc.
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 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)))
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))