#9 FsumFE calls FSUM.EXE in wrong way when there are non-ascii charactors in file path.

v1.0_(example)
open
nobody
5
2013-08-06
2013-08-06
arqr33
No

Hello, I really appreciate for this nice and versatile FrontEnd for fsum. Fsum.exe is the fastest free hash tool in the world, I think. I can figure out file's hashes FAST, thanks to FSUM, and also EASY, thanks to FsumFE.

Unfortunately I've faced a problem with FsumFE. FsumFE works just fine if I don't check "Use fsum" on options panel. But when I check it, FsumFE would not works properly with certain files.

I've tested a few things and figured out that the certain files have non-ascii path. Technically, there are two issues which are related with this problem.

The first, FsumFE calls fsum.exe with UTF-8-like encoded options. Windows uses UTF-16 for its file system, so fsum.exe cannot recieve correct filepath.

For example, when I try hashing "C:\Documents and Settings\username\デスクトップ\test\テスト.txt", which is a file on Desktop of Japanese Windows XP, FsumFE calls below.

fsum.exe -d"C:\Documents and Settings\username\繝・せ繧ッ繝医ャ繝予test" -jm -jnc -crc32 -md5 -sha1 "繝・せ繝・txt"

Correct call should be like below:

fsum.exe -d"C:\Documents and Settings\username\デスクトップ\test" -jm -jnc -crc32 -md5 -sha1 "テスト.txt"

"デスクトップ" and "テスト" in the filepath/filename part was encoded in wrong way. Another example can be found on Korean Windows 7, testing "C:\시험\테스트.txt":

fsum.exe -d"C:\?쒗뿕" -jm -jnc -crc32 -md5 -sha1 "?뚯뒪??txt"

which should be:

fsum.exe -d"C:\시험" -jm -jnc -crc32 -md5 -sha1 "테스트.txt"

The worst part of this issue is, FsumFE cannot even START if FsumFE itself is in non-ascii path!

Above issue can be temporally solved by using fsum directly, not through FsumFE.

The second issue is the problem of both FsumFE and fsum.exe. When I make an attempt to hash file that its path has unicode charator, FsumFE doesn't work. Even if I use fsum.exe without FsumFE it cannot be done. Example in Korean Windows 7:

C:\test>fsum -d"C:\test\ハンバーガー" -jm -r -sha1 "."

SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337
Implemented using SlavaSoft QuickHash Library <www.slavasoft.com>
Copyright (C) SlavaSoft Inc. 1999-2007. All rights reserved.

C:\test\ハンバ?ガ?\ - no such directory

This result can vary from OS language. Example in Japanese Windows XP:

C:\test>fsum -d"C:\test\ハンバーガー" -jm -r -sha1 "."

SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337
Implemented using SlavaSoft QuickHash Library <www.slavasoft.com>
Copyright (C) SlavaSoft Inc. 1999-2007. All rights reserved.

; SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337 <www.slavasoft.com>
;
; Generated on 08/07/13 at 05:39:37
;
25089bc146f4a9817bc3f692fb35f94b9a4470ca ?SHA1*test.txt

"C:\test\ハンバーガー" contains Japanese charactors. Especially "ー" is treated as local codepage charactor in Japanese Windows, but is treated as unicode charactor in Korean Windows.

I will report the second issue to Slavasoft too, but you can solve this with workaround even if fsum.exe has a bug. The answer is 8.3 name. In default settings, Every modern windows use legacy 8.3 naming on filesystem. (Just type dir/x on cmd window to see it.) Example on Korean Windows:

C:\test>fsum -d"C:\test\ハンバ~1" -jm -r -sha1 "."

SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337
Implemented using SlavaSoft QuickHash Library <www.slavasoft.com>
Copyright (C) SlavaSoft Inc. 1999-2007. All rights reserved.

; SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337 <www.slavasoft.com>
;
; Generated on 08/07/13 at 05:48:54
;
25089bc146f4a9817bc3f692fb35f94b9a4470ca ?SHA1*test.txt

Discussion