#42 error reporting issues

None
closed-fixed
nobody
None
5
2014-07-04
2013-09-28
Liviu
No

Running rhash v1.3.0 stock win32 build under xp sp3.

  1. There seems to be no warning that files were skipped due to, for example, sharing violations. I think there should be at least an option, if not the default, to report the files that could not be processed - instead of silently ignoring the error. For example, under windows, the %userprofile% directory has at least of two files ntuser.dat.* which are exclusively locked by the system at all times. Thus, it is not possible for rhash to open/hash them, but this should still be reported as a failure, rather than be silently ignored.

  2. When target is a wildcard, rhash issues warnings (to stderr) for each subdirectory matching the wildcard. Don't think this is warranted, since that's not an error, and the user who entered the wildcard certainly meant "files" not "directories".


C:\tmp>rhash --md5 -- "%userprofile%\*.*"
RHash: H:\Documents and Settings\liviu\Application Data: Is a directory
[...]
13cfb479e23f335eb4f1f4a80602757a H:\Documents and Settings\liviu\ntuser.ini
9038e4d82beefb06d8a10c929ddedc70 H:\Documents and Settings\liviu\ntuser.pol
[... but there is no mention of ntuser.dat and ntuser.dat.log which couldn't be hashed ...]
RHash: H:\Documents and Settings\liviu\PrintHood: Is a directory
[...]


Liviu

Discussion

  • Aleksey

    Aleksey - 2013-10-01

    Thanks for reporting. I agree about the 2-nd proposition.

    But about the first one. Consider user runs
    rhash.exe --md5 *.* > sums.md5

    Windows will create sums.md5 file to recieve program output and lock it for writing. Then RHash will try to hash it and will report:
    sums.md5 - access denied

    It looks to me that program shall not report error in this case, and such behavior is incompatible with (1).

     
    Last edit: Aleksey 2013-10-02
    • Liviu

      Liviu - 2013-10-01

      You raise a good point, and there doesn't seem to be a consensus on this. For example, Microsoft FCIV ignores access-violations silently (as rhash does now), while Slavasoft FSUM does report the errors (including its own >sum.md5 if applicable e.g. "DENIED ***** sum.md5").

      IMHO all file errors should be reported by default, even more so in the case of a utility like rhash meant to verify integrity of filesets.

      That said, I can see the inconvenience of getting bogus errors during common usage such as "rhash.exe --md5 . >sums.md5". I think this could still be resolved in a couple different ways, while otherwise reporting all actual errors.

      1.a. When the output file is specified on the command line ("-o" instead of ">" redirection) rhash could check each file error against its own output file, and suppress reporting of the error if the full paths match.

      1.b. Rhash could add a command line switch to exclude files(s) which would allow the user to explicitly exclude the output file e.g. "rhash . --exclude sum.md5 >sum.md5" (this would work regardless of the output file being specified with "-o" or ">").

       
      Last edit: Liviu 2013-10-01
  • Aleksey

    Aleksey - 2013-10-02

    Ok, you convinced me.
    1.a. is good solution. :)

     
    • Liviu

      Liviu - 2013-10-02

      Great! Many thanks.

       
  • Aleksey

    Aleksey - 2014-01-10

    Done in the RHash 1.3.1.

    • print warnings on sharing violations
    • ignore files specified by -o <out-file> and -l <log-file>
    • show no warnings for directories while expanding wildcards
     
  • Liviu

    Liviu - 2014-01-11

    Both #1.a and #2 work nicely in v1.3.1 now. Thanks!

    However, I am still seeing files being skipped silently, without warning. In hash-backup-verify scenarios, it is important to know whether any files were missed during hashing.

    Following is copied from a win7x64.sp1 cmd prompt at the %userprofile% directory. It shows a directory with 4 files, 3 of which are locked by the system. RHash v1.3.1 skips over those 3 files without any warning. I was expecting it to report the sharing violation at that point.


    C:\Users\liviu>dir /a-d
    Volume in drive C is WIN7
    Volume Serial Number is 5EF3-B81C

    Directory of C:\Users\liviu

    01/11/2014 12:54 AM 1,310,720 NTUSER.DAT
    01/11/2014 12:54 AM 262,144 ntuser.dat.LOG1
    11/06/2012 12:43 AM 0 ntuser.dat.LOG2
    11/06/2012 12:43 AM 20 ntuser.ini
    7 File(s) 2,686,996 bytes
    0 Dir(s) 431,055,527,936 bytes free

    C:\Users\liviu>type ntuser.dat
    The process cannot access the file because it is being used by another process.

    C:\Users\liviu>type ntuser.dat.log1
    The process cannot access the file because it is being used by another process.

    C:\Users\liviu>type ntuser.dat.log2
    The process cannot access the file because it is being used by another process.

    C:\Users\liviu>rhash --md5 -- *.*
    6fc234ad3752e1267b34fb12bcd6718b ntuser.ini

    C:\Users\liviu>rhash --version
    RHash v1.3.1

    C:\Users\liviu>


    Liviu

     
  • Aleksey

    Aleksey - 2014-01-11
    • status: closed-fixed --> open
     
  • Liviu

    Liviu - 2014-03-19

    Just wondering, is there an official v1.3.2 release anywhere near?

    Liviu

    P.S. I think the changelog (and possibly manual) pages at http://rhash.anz.ru/ need updating, too.

     
  • Aleksey

    Aleksey - 2014-03-21

    Thanks for noticing the outdated pages! :)
    I've fixed them.

    The next version is half done, but RHash is written just for fun and there is no release schedule ;)

     
  • Liviu

    Liviu - 2014-03-22

    Thanks for sharing the fun ;-) rhash is among the preciously few command line utilities on the windows scene with Unicode support, subdirectory recursion, multiple hashes and output formats.

     
  • Aleksey

    Aleksey - 2014-07-04
    • status: open --> closed-fixed
     
  • Aleksey

    Aleksey - 2014-07-04

    Fixed in v1.3.2.

     

Log in to post a comment.