0

What are the QuickSFV comments at the end of an SFV file based on?

25-Monty_Python-The_End-EOS.mp3 D387716E
;Q1-1c11727069c13b6
;Q1-///4AA==

In version 2 it had a line more:

cowiso-xvid-yrrol.part48.rar 60C3AB2E
cowiso-xvid-yrrol.part49.rar E50D18BC
;Q2-1c25890ae82a640
;Q2-8KmPHkmiwgE=
;Q2-////////gA==

SFV files have different kinds of comments depending on the tool, but only QuickSFV edits the file and stores weird information at the end. See the SFV FAQ for more information about the SFV file format.

The ; indicates the start of a commented line and Q1- and Q2- seems to refer to the QuickSFV major version. I looked through the version history and these are my findings so far:

v1.50b changes: A small bug was fixed when the last line of an .SFV file did not end with a CR or LF. The "Previously Checked Files" database would be tacked on to the end of that line instead of on a line by itself.

v1.51 changes: If an SFV file already has an existing DB embedded in it, QuickSFV will use it but not update it or remove it.

It's called the "Previously Checked Files" database.

v1.60 changes: A unique signature is now recorded within the Previously Checked Files database to keep track of whether the database was created by the current user or a different user. This will help when SFV file creators verify the files and leave the Previously Checked Files database in place when uploading the SFV file. This signature is simply a random number and contains no specific information to the machine it is running on. It is generated during install or if the corresponding INI setting is missing. Upgrading will maintain this signature as long as you install to the same folder as the existing version of QuickSFV. Installing to a new folder will reset this signature causing QuickSFV to ignore the Previously Checked Files database when verifying. Uninstalling QuickSFV will erase the signature.

The random number is in a quicksfv.conf file that can be found in C:\Users\User\AppData\Local\QuickSFV for version 3 and looks like Signature=1234567890, a 10 character number and seems to be random. Version 2 ini is located at C:\Program Files (x86)\QuickSFV\QuickSFV.ini and contains a 15 character hex string. In the above examples, this is the first line. This line will stay the same for a system and can identify an install.

I'm not convinced that this string is still completely unique or random! Random SFV files on the internet seem to start with 1c or 1d. Maybe it is based on the timestamp of installation? For my test it started with 1d, while older files all seem to start with the other one.

After this suspicion, I got the following result from experimentation:

Signature=1d17fc36609ef78
      ;Q2-1d17fc7bfca4eee
      ;Q2-1d17fc830b747a9

It's clearly an incrementing number. How to turn this into a date or is it something else?

v2.00 changes: Added an expiration function for the Previous Verified DB. This is an .INI setting allowing you to specify the maximum date of the DB before assuming it is old and reverifying all of the files. It defaults to no expiration, but [...] Added right-click menu option to remove all Previously Verified DB info from the current .SFV file.

The time stamp of a file is modified after changing the database. This is how this feature works.

And then there are one or two more lines to explain. What exactly do they represent? How does this database work?

1

I looked into this a bit today after coming across your post.

I can't comment much on the first line. As you know, it's the signature written when QuickSFV is installed. Unfortunately that's all I know as well.

The second line is a Base64-encoded FILETIME timestamp from Windows. According to Microsoft, this value is "the number of 100-nanosecond intervals since January 1, 1601 (UTC)." QuickSFV writes the current system time when checking/verification is finished (including when it just checks its database without checking/verifying any files).

The third line a Base64-encoded set of flag bits. 0 means missing or bad, and 1 means verified okay. If there's 1 file there's exactly one flag bit, and if there are 1000 files there are 1000 flag bits.

Hopefully this helps anyone trying to make use of the Previously Checked File database in .sfv files.

| improve this answer | |
  • Thanks for figuring it out! The only unknown left now is how exactly the "random number" of the first line relates to a point in time. – Gfy Jun 3 '16 at 18:38
1

The signature isn't random. It's the same type of Windows timestamp. I think it's likely unique enough in all but the extreme edge case but doesn't include any sort of identifying information about the user or system. I think it's a great solution of needing a 'unique-enough' identifier but not truly identifying the user/computer. Kinda cool if you ask me.

I can also tell you, the signature is used to determine if YOUR system has verified the files or not. If the signatures don't match, then it will ignore the flags and re-verify every file. Also, the reason for the timestamp is probably to compare it with the check-summed files. If one of the check-summed files has a later timestamp than what's stored in the .sfv file, then that file most likely has been changed and must be re-verified.

| improve this answer | |
  • Please provide a reference for this to turn it into a good answer. – DavidPostill Jun 24 '16 at 17:08
  • That's what I noticed yes, but how exactly does it map to a time stamp? It's not a Base64-encoded string like the second line. Maybe it is just the hex representation? I haven't tested it yet. I did understand correctly that it was used to speedup local checking. The exact meaning of its origin is not important for how the tool uses it. – Gfy Jun 25 '16 at 14:41
  • The signature is a hex representation of the current system time as a FILETIME at time of installation. – Johanne Jun 27 '16 at 16:07
1

I made a webpage to paste in an SFV file and the result will roll out: http://rescene.wikidot.com/quicksfv

The given answers are correct. Using JavaScript for this was the tricky part :)

  • The signature is a FILETIME timestamp encoded as one big hexadecimal number: the high order bits are before the low order bits. The leading zero of the first byte is not shown.

  • The second line is a FILETIME timestamp from Windows, but the structure is Base64 encoded. The first 32 bits are the low order bytes.

  • The third line a Base64-encoded set of flag bits.

| improve this answer | |
0

That's interesting but surely this invalidates the purpose of the tool? How do you know that a corrupt file is corrupt if the database reports it has been verified OK?

For example, a system with an undetected faulty memory module may silently introduce corruption into files without changing their sizes or timestamps. These files will not be detected as corrupt by QuickSFV due to its database feature.

| improve this answer | |
  • The signature allows QuickSFV to see whether it ran on the system before or not. If not I assume it will always run the check again. In case it's the same system it can use the last checked time stamp to decide whether or not to run the verification again. When it's the same day it can ignore the good files each time the user triggers a recheck after bad files replaced (fast). After a for me unknown time QuickSFV will always do the checks again, thus still suitable to check for corruption afterwards. – Gfy Dec 8 '19 at 21:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.