hashbert issues and bugs

Hashbert issues and bugs

Tested filesystems

Only tested on linux. Other filesystems (filesystem / operating system combinations) haven't bin tested.


Localtime issue

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 switches).

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 ...

Universal_Disk_Format issue

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))