SharpSFV - A Spiritual Sucessor to QuickSFV

[L33THAK0R]

I'm not sure if this is *really* appropriate for this forum, but I did design this around features I'd like to have as a compression hobbyist, so I thought I'd share it here, on the off-chance someone else finds it useful/interesting.

A while ago I read a forum post about xxhash3 and it's improvements over md5 in terms of speed and reliability. I meant to use it as motivation to create a GUI with support for the algorithm, as I've had my own gripes with QuickSFV, but have yet to find a suitable alternative, save for QuickDash (https://github.com/iamtakingithard/QuickDash), which was developed by a good friend of mine, but lacked a GUI, and given my complete lack of experience with Rust, I didn't feel confident trying to.

Anywho, over the last few days I've actually put in a bit of work and gotten a decent prototype working, that I'll be implementing in my own workloads/projects and replacing QuickSFV. It's definitely not a perfect product, I've no experience with C++, and it's challenges, and opted instead for C# which was much easier to get my head around, but relies on the .NET 8.0 framework. In the future I would like to eventually port this to C++ to ensure longer term compatibility with Windows 10/11, but I've currently got no experience with C++ so I'll need to do a bit of learning in the interim. The other downside is the size of the compiled binary, I wasn't able to get trimming working, the final size clocks in at 287 KiB, to QuickSFV's 114 KiB. Again I'm sure if I port this to C++ or Rust even the size will be smaller, but that's a project for another day.

SharpSFV has feature parity with QuickSFV, in addition it's key features include primarily the addition of the ultra-fast xxHash-3 algorithm and native recursive folder scanning. Unlike QuickSFV, it offers robust handling of Unicode characters and long file paths to prevent errors verifying files on modern filesystems, and introduces productivity enhancements such as real-time list filtering, granular dual-progress tracking for individual files, clipboard integration for batch processing, and a simpler portable configuration file.

Anyone interested in checking out the project can find it at the following repo:


https://github.com/Wishwanderer/SharpSFV

[luxuse]

i cant find any bat cammand in the readme any auto check or other type ?

[KaktoR]

You mean command line?

Doesn't look like this tool has one. But would be good imo.

Somehow I dislike tools that don't have any command line arguments.

[L33THAK0R]

i cant find any bat cammand in the readme any auto check or other type ?

I'll update the readme, apologies.

the usage in the command line is simply sharpsfv.exe <CHECKSUM_FILE>

supported extensions include

*.sfv
*.md5
*.xxh3
*.sha1
*.sha256

I'm unsure what you're referring to by "auto check" / "other type". Again apologies for the lack of information.

[L33THAK0R]

You mean command line?

Doesn't look like this tool has one. But would be good imo.

Somehow I dislike tools that don't have any command line arguments.

I made it more as an extension of QuickSFV, with support for xxhash3 and some QoL features I've always wanted, since I use QuickSFV for a lot of my testing, if there are any arguments you think would be useful I'd be happy to add them in. I've always used a Shell Extension tool for generating checksums rather than using the command line, so I didn't think to add any initially.

[KaktoR]

Does not work here.

SharpSFV.exe "test.sfv"

Even absolute paths doesn't work.

[L33THAK0R]

Hello.

Could you please let me know if it is possible to move the core logic of SharpSFV into a DLL (class library)?

I would like to use the SFV/hash calculation and verification functionality from another application, without running the exe or GUI.

For example:

move the core logic into a separate library project...callback
keep the current application as a wrapper over it
I understand if this is not planned — I just wanted to ask.

Thank you for the project.

I think this would be an entirely different project, since SharpSFV relies heavily on the System.IO.Hashing package for checksum validation/generation. Unfortunately I've got no experience with creating DLLs, I'll have a look into it over the weekend.

[L33THAK0R]

Does not work here.

SharpSFV.exe "test.sfv"

Even absolute paths doesn't work.

I've updated the latest build and binary to add some basic debugging if it's failing to launch, I tested this on a couple systems and was satisfied with the validation results, do md5/xxh3 hashes work? Additionally if building from source (I updated this readme accordingly) the command dotnet publish -c Release -r win-x64 --no-self-contained -p:PublishSingleFile=true will ensure the external hashing library will be included. Apologies you've had this subpar experience so far.

[KaktoR]

Other hash algorythms working fine, just sfv/crc32 (I believe) doesn't work here.

Edit: I found out why it don't work. If you create SFV with SharpSFV, I was asuming the hashes are stored as crc32 hashsum, but it looks like md5 or something else.
I am creating hash files with other applications, like hashcheck shell extension.

So basically If I want to do hashchecking with SharpSFV + command line + SFV extension, I have to change options "Default Hash algorithm" in SharpSFV to "CRC-32 (SFV)".

Edit 2: All other applications I worked with stored CRC32 hash if you export them as SFV file format as default. If you use other programs to create sfv hash files and want to check them with sharpsfv, then this attempt will fail.

Example:
https://i.imgur.com/y6ulhWH.png

[L33THAK0R]

Other hash algorythms working fine, just sfv/crc32 (I believe) doesn't work here.

Edit: I found out why it don't work. If you create SFV with SharpSFV, I was asuming the hashes are stored as crc32 hashsum, but it looks like md5 or something else.
I am creating hash files with other applications, like hashcheck shell extension.

So basically If I want to do hashchecking with SharpSFV + command line + SFV extension, I have to change options "Default Hash algorithm" in SharpSFV to "CRC-32 (SFV)".

Edit 2: All other applications I worked with stored CRC32 hash if you export them as SFV file format as default. If you use other programs to create sfv hash files and want to check them with sharpsfv, then this attempt will fail.

Example:
https://i.imgur.com/y6ulhWH.png

The latest release should have resolved these issues. The issue was with Big/Little Endian state of the checksum, as well as with the formatting of the checksums, I hadn't tested legacy sfvs and wrongly assumed compatibility. Release notes are in the GitHub repo, for those who aren't as interested, said release notes are as follows:


Fixed issues with legacy *.sfv support (Big/Little Endian conflicts)
Added Multi-threading support (Automatically determined by whether the target drive is a HDD/SSD)
For files larger than 1 GiB, these files will be pinned at the top of the list, with progress tracked.
Re-worked numerous aspects of the code-base for greater efficiency and stability.
Large data sets via drag & drop have been stabilised and confirmed (test sample contained 500.000 files of varying sizes)
Added sound cues to play when verification has finished.
Some additional edge cases have been resolved.
Upgraded from .NET 8 to .NET 10 for some minor performance improvements, this has resulted in a slightly larger binary.
Re-wrote source code comments for clarity.
Minor memory improvements.

[KaktoR]

Thanks. The issues are fixed with the update.

[luxuse]

Great update and thanks for updating the README! Everything works really well, though I hope in the future there might be a version without the .NET dependency. Really appreciate your work! :cool:

[L33THAK0R]

Patch Notes:

- Significantly overhauled logic for HDD/SSD identification, added a debug info window to catch future edge cases.
- Abstracted monolithic class into partial classes, code is still a bit spaghetti but easier to manage.
- When the time elapsed tab is enabled, total time is also tracked and appears upon completion, this was mainly to benchmark the actual difference between HDD and SSD mode. On a 7 GiB sample containing 5 files of varying size, using HDD mode saved ~ 5 seconds (~27 using SSD/Parallel, ~22 using HDD/Sequential mode). These improvements were mirrored over other tests, however I didn't record the results at the time. Just included this note to demonstrate that parallel operations aren't always optimal.

Additional Notes:

The SSD/HDD detection feature has turned out to be a real bugger of an issue, the issue was not with standard drives but encrypted drives, where previous volume IOCTLs checks weren't returning any valid values, at least with VeraCrypt encrypted drives. New checks return to checking the "friendly name" and analysing it for key words, i.e. SSD, NVMe, Flash, M.2. Under the help menu in the toolbar, is a disk info debug box, with a clipboard friendly result reading. If anyone has a drive which is wrongly identified and can submit the debug info, I should be able to improve these detection layers.

[L33THAK0R]

Great update and thanks for updating the README! Everything works really well, though I hope in the future there might be a version without the .NET dependency. Really appreciate your work! :cool:

If/when I learn C/Rust down the road, I'll give it a crack, unfortunately, at least currently, I'm not equipped to make a more portable application.

[L33THAK0R]

Patch Notes:
- Replaced LockWindowUpdate with WM_SETREDRAW to eliminate desktop flickering and visual artifacts during bulk file updates.
- Replaced string-based status tracking with a lightweight ItemStatus byte enum to significantly reduce memory usage and accelerate sorting operations.
- Switched worker threads to synchronous I/O and hashing to remove Async State Machine overhead, maximizing throughput on high-speed NVMe drives.
- Implemented modulo-based throttling in the UI update loop to drastically reduce CPU cycles spent on system time checks during high-speed processing.
- Split the monolithic Form1 and Helpers files into specialized partial classes and namespaces to improve organization.
- Centralized P/Invoke definitions into a dedicated Win32Storage class to isolate native code and resolve compiler ambiguity errors.
- Optimized memory usage by refactoring the data model to store hashes as raw byte arrays instead of strings.
- Reduced garbage collection pressure by implementing ArrayPool for buffer reuse within the hashing engine.
- Corrected the project build configuration to disable incompatible trimming flags while maintaining a lightweight single-file executable.
- Implemented a new "View" menu to optionally toggle Hash/Expected Hash columns and lock column ordering.
- Added a "Show Full File Paths" option that dynamically adjusts the File Name column's maximum width limit to the longest text length plus a 25px buffer.
- Integrated a "Show Duplicates" filter that groups files by hash and enables conditional "Copy Duplicates" and "Delete Duplicates" batch script generation.
- Added a "Delete BAD Files" script generator that automatically enables only when verification errors are detected.
- Updated all save dialogs to default to the root directory of the scanned files rather than the application path.
- Removed "Script Saved" message boxes to allow for silent, uninterrupted script generation.
- Fixed column resizing logic to enforce "Hard Stop" limits (0.75x–1.5x) using event cancellation, eliminating visual snap-back artifacts.
- Enabled horizontal scrolling on the main list view to ensure long file paths remain viewable.
- Replaced the hashing engine with a Producer/Consumer pattern using System.Threading.Channels to decouple high-speed file scanning from processing logic.
- Implemented System.Buffers.ArrayPool<byte> to recycle memory buffers, eliminating massive Garbage Collection overhead during large batch operations.
- Optimized the file scanner to batch UI updates in groups of 2,000, allowing raw disk read speeds to saturate without freezing the interface.
- Replaced the performance-heavy "Pin-to-Top" mechanism with a scalable SplitContainer and secondary ListView for tracking active large files.
- Added GDI+ resource caching to the Virtual Mode rendering pipeline to prevent system handle exhaustion and crashes during extensive scrolling.
- Fixed critical thread-safety race conditions by ensuring list counts and progress limits are only resolved on the UI thread.
- Enhanced the user interface with multi-colored status statistics, synchronized column alignment, and a debounced search filter for responsive interaction.
- Replaced the object-based data model with a Structure of Arrays (SoA) architecture to eliminate per-file object overhead and maximize CPU cache locality.
- Switched from FileStream to System.IO.RandomAccess for zero-allocation file reading, creating a direct "disk-to-memory" pipeline.
- Hoisted hashing buffers and algorithm instances to thread-local storage to prevent Garbage Collection churn during batch processing.
- Implemented a custom String Pool utilizing .NET 10's AlternateLookup to deduplicate repetitive path strings and significantly reduce memory usage.
- Enabled Dynamic Profile-Guided Optimization (PGO) in the project settings to let the JIT compiler optimize hot loops based on runtime execution data.
- Refactored the producer-consumer pipeline to pass lightweight structs (FileJob) between threads instead of heap-allocated class objects.
- Updated the Virtual ListView to render directly from primitive arrays and cache hex string conversions, eliminating UI scroll lag.

Additional Notes:

Processing is 1.61x faster than v2.30, memory usage has been reduced by 84%. SharpSFV is now 16.53x faster than QuickSFV (when verifying using pre-generated MD5 hashes), with QuickSFV only being able to process around 50% of the provided benchmark MD5 file, before crashing.

[Razer-785]

Hello i am sorry if this is a stupid question but how can i make the checksum without the folder path. i am trying to implement this into a installer/setup but i don't want to have to edit the checksum file each time to remove the file path.

the file named "checksums-original.txt" is what i get if i do it normally copy the folder path and press ctl+v in the software.

and the file named "checksums-fixed.txt" is what i need, i already tested it and it works.

but if you can help me with this that would be great, also im kinda new so im sorry if this is kinda weird or does not make sense.

PS. Awesome program works really well:)

[L33THAK0R]

Hello i am sorry if this is a stupid question but how can i make the checksum without the folder path. i am trying to implement this into a installer/setup but i don't want to have to edit the checksum file each time to remove the file path.

the file named "checksums-original.txt" is what i get if i do it normally copy the folder path and press ctl+v in the software.

and the file named "checksums-fixed.txt" is what i need, i already tested it and it works.

but if you can help me with this that would be great, also im kinda new so im sorry if this is kinda weird or does not make sense.

PS. Awesome program works really well:)

In the options tool-bar, you've enabled the "Always Save Absolute Paths" setting, this option is disabled by default. If you're unsure of the difference between absolute and relative paths, a search or two should clear up any confusion.

[L33THAK0R]

Substantial update was pushed to the repo last night, changelog is as follows:

v2.50 Changelog

New Features


Jobs Queue Mode: Added a dedicated batch processing queue that handles multiple folders sequentially with automatic checksum generation and detailed status reporting.
Advanced Options Toolbar: Implemented a toggleable toolbar offering path prefix injection, wildcard file filtering, and directory recursion controls.
Reset Configuration: Included a help menu option to reset all configuration settings to defaults and automatically restart the application.


Improvements


Processing Strategy (I/O): Replaced the legacy HDD toggle with a selectable Processing Mode (Auto, HDD, SSD) to override errors in the automatic detection logic.
Path Storage Logic: Refined path saving behavior with a new Path Storage menu to enforce Relative or Absolute paths and handle cross-drive scenarios correctly.


Bug Fixes


General Fixes: Fixed critical crashes related to list virtualization and threading race conditions while resolving display inconsistencies between operating modes.


Known Issues


Currently the new Jobs Mode may cause some slight performance issues, I'm working on resolving these, but I'm satisfied with the state of the current build.
If you attempt to start a job whilst verifying an existing checksum, this may result in a crash, I'm working on fixing this.

[FitGirl]

Thanks for the tool, but could you also upload "static" build w/o need to install Dotnet for endusers?

[L33THAK0R]

Thanks for the tool, but could you also upload "static" build w/o need to install Dotnet for endusers?

Unfortunately not, I'm only somewhat alright with high-level languages, I have no experience with low-level languages like C++ & Rust. My current solution searches for the .NET 10 installation at the default path (Assuming C: is the system drive), if not found my installer enables the .NET 10 redist download option (under my redist menu), and installs post-install. It's not perfect but it's the only viable solution I've got currently. C# is an easy language to learn but is mainly designed to work with the .NET runtime/libraries. Maybe down the road I'll look into porting the codebase to something independent, but the costs far outweigh the benefits. Even if using SharpSFV without .NET 10 being installed, there is enough logic embedded in the application to direct the end-user to the appropriate download page.

[Masquerade]

^^
FitGirl means for the .NET runtime to be built into the compiled executable, please see below:
https://stackoverflow.com/questions/71209803/how-to-build-a-single-exe-file-with-static-net-runtime-from-a-c-sharp-wpf-pr

However in my experience, this leads the compiled file to be 30-40mb in size.

[L33THAK0R]

^^
FitGirl means for the .NET runtime to be built into the compiled executable, please see below:
https://stackoverflow.com/questions/71209803/how-to-build-a-single-exe-file-with-static-net-runtime-from-a-c-sharp-wpf-pr

However in my experience, this leads the compiled file to be 30-40mb in size.

Given the 81-298X increase in file size (~110MiB uncompressed, ~30.5MiB compressed (xtool+srep+lolz), versus not including the .NET runtime, I wouldn't even consider this a valid alternative.

[L33THAK0R]

A couple smaller QoL updates, can't think of any additional front-end improvements, or significant back-end optimisations. If anyone has any suggestions or bugs to report, I'll keep an eye on the GitHub issues.

v2.52 Changelog

New Features



Pause/Cancel Operations: Pause/Cancel buttons are now available for both regular-mode and job-mode.
Comment Parsing Support: Using the "//" prefix, users can now integrate comments within their checksum files, which will appear in a pinned panel at the top of the main form.



Improvements


Window Usability: Window dimensions now have a strict minimum size, with a horizontal scrolling bar implemented for easier navigation.
Window Responsiveness: RunVerification logic has been overhauled to operate in a 2 phase process. Previously the benchmark would take ~119 seconds to complete, versus ~74 seconds on repeat trials, due to Windows caching the Master File Table in memory. I'd overlooked this in testing, it was a hack-job that was never properly addressed. The new logic results in only ~5 seconds of latency versus the previous ~45 seconds.


Bug Fixes



Performance issues introduced with the "Jobs Mode" feature have been resolved.
If you attempt to start a job whilst verifying an existing checksum, no crashes will result.

[L33THAK0R]

Merged another project I'd been working on, essentially a stripped down version of SharpSFV that focused on shell integration, mimicking kliu.org's HashCheck utility, but with xxhash3 support. Made a few improvements to the front-end I'd overlooked, as well as a bit of tidying up the back-end, made everything a lot more stable, more streamlined. Quite happy with how it's turning out, outside of course the increased binary size.


v2.6 Changelog

New Features

Shell Integration: Added Explorer context menu integration with single-instance file queuing and file associations.
Mini Mode: Created a streamlined UI for context menu operations that automatically saves and exits upon completion.
CLI Mode: Implemented a -headless argument for command-line usage with console-based progress reporting.
Taskbar Integration: Added taskbar progress mirroring with color-coded status indicators (Green/Red/Yellow).
Bad File Tools: Added conditional options to move or rename corrupt files when errors are detected.
Clipboard Compare: Implemented a feature to instantly verify a selected file against a hash stored in the clipboard.

Performance & Metrics


Smart Buffering: Optimized I/O performance with dynamic buffer sizing (8MB for HDD, 512KB for SSD).
Metrics: Added real-time throughput (MB/s) and ETA calculations to the status display.
Timing: Ensured processing time is tracked internally for all items regardless of column visibility.


User Interface & Experience


Menu Overhaul: Replaced the Jobs menu with a Mode selector and consolidated Copy actions into a unified "Copy Entry" format, identical to layout seen in generated checksum files.
Job Mode: Added a Time column to the Job Queue and fixed layout stability issues by disabling incompatible view options.
UX Improvements: Removed the Stop confirmation prompt and enabled multi-select support for context menu actions.


Fixes & Maintenance


Bug Fixes: Resolved issues with Job Mode file verification, taskbar progress desyncs, and layout corruption.
Refactoring: Consolidated UI layout logic into a single class and standardized internal algorithm enumerations.

[L33THAK0R]

Added a very minor v2.61 update, not even really worth patchnotes for, just fixed some edge cases where the legacy SFV support was breaking down. Main purpose of this push was re-writing documentation across every significant class, because Lord knows I'm going to forget how some of this spaghetti code works in the future.