Talk:File verification

message: There are clear situations where the checks listed here, will not work.
The situations are complex and simple.  The data that gets checked can be data is buffers and caches etc, in drive electronics, chipset, memory, virtual paging and operating system. Apart from compensating errors producing false positives, the software/hardware may fetch the values from the data chain before the recording has hit the dusk surface. A practice is write and read short sections encourages this.  So, all the chain has to be flushed to disk and values collected from disk surface (there is potential for corruption between read from disk getting to software, but most of the time that will be negligible).  The other side issues, I can't remember, as I am not an engineer in these areas, and not are many software writers).  However, I encourage an editor to find definite information on this, and an engineer in this area, to get correct information.
It is difficult to get software that guarantee perfect copy.  Which brought me to this article.  In situations of backup of vital data and situations where thousands of terabytes maybe involved, this can lead to an accumulation of errors.
For instance, of importance to educating readers, some users in video production mistakenly copy files to new drives regularly as an archival strategy.  The data is compressed, and such errors can lead to major image problems in a frame or a group of frames in heavy compression schemes, which can be half a second of footage, and can be unrecoverable.  In normal daily filming, such errors may not come up, but in long term archive replication vital footage that needs to be kept can be corrupt.  Hard drives have a very limited life, requiring transfer eventually, cheap flash storage even down to a year.  So, transfer in these usage situations is responsible, but selection of competent software is an issue.
In an everyday user's life data recording, the same situation happens.  The user's data can be many terabytes, even thousands of terabytes going corrupt or being copied in a fashion which can go corrupt.  The basis of much cloud storage, is privacy invasion, as it is rather expensive to offer at reduced prices, as it is in much of the internet economy commonly commented on.  For each person there is privacy concerns, and once collected the data 24 hours a day can pass onto others.  So, backup to local storage is part of an answer.
: Here is a page that lightly discusses it, but not to it's interaction with checks on unwritten data.  The software here focuses on byte to byte comparison instead, which is top level verification.  The page is no longer maintained, as the developer passed way in 2017.
http://www.xxcopy.com/xxtb_045.htm
— Preceding unsigned comment added by 49.197.126.248 (talk) 10:02, 15 February 2021 (UTC)
thread_title:  Inadequate scope. 

message: Per comments at  Wikipedia:Deletion review/Log/2021 September 1, maybe we could merge something here? The problem is that the sfv article has next to no footnotes. Perhaps someone could rewrite it into a properly referenced section here? Ping User:S Marshall who suggested this as a merge target, if I understood him correctly, and User:Cryptic, who also mentioned Cyclic redundancy check as another target? Piotr Konieczny aka Prokonsul Piotrus| reply here 02:46, 9 September 2021 (UTC)
replies: text: Both articles should be cleaned up.  • Sbmeirow • Talk • 10:48, 9 September 2021 (UTC)

text: IMO, the SFV article should focus on the  format proper, rather than attempt to cover the fundamentals of file integrity checks. This includes compatibility differences between programs that draw additional metadata from specially-formatted comment lines, support for multiline comments (useful for banners) and other syntactic extensions. This should be plenty of material for the SFV page. OmenBreeze (talk) 22:39, 21 September 2022 (UTC)
thread_title:  Merge from [[Simple file verification]] 

message: Re your change, "false negative" means that a  given condition, when tested, is found to be false when it is not.  False positive means the condition is found to be true when it is not.  The "given condition" here, as stated in the paragraph in question is the "file has not been corrupted".  A hash collision results in the file being corrupted but testing as uncorrupted.  That is a false positive for uncorrupted. SpinningSpark 06:06, 23 July 2022 (UTC)
replies: text: Ack. Thanks for the clarification. Luchostein (talk) 21:07, 22 November 2022 (UTC)
thread_title:  False positive or false negative?