验证写入文本文件的文本 [英] Validate text written to a text file

问题描述

我需要一些关于如何使用我的Vb.net应用处理独特情况的建议。此应用程序创建一个新的文本文件，它基本上是不同文本文件的子集。该应用程序的工作原理如下：

•将源文本文件从网络驱动器复制到本地计算机驱动器

•打开复制的源文本文件以供阅读

•打开一个新的文本文件进行写入

•读取源文件行＃1并将结果存储在一个变量中，然后将变量中的内容写入新的文本文件

•重复上述步骤X次

•逐行读取源文本文件并搜索包含Y的行

•将该行复制到新文本文件

•继续逐行读取源文本文件并将数据复制到新文本文件，直到找到包含Z的行

•关闭两个文本文件

•将新文本文件移动到另一个文件夹



上述代码已在30多台不同的计算机上运行至少8年直到上周我们才有问题。然后上周我们突然发现其中一个新文本文件在1行与源文件上有所不同。几天后，我们注意到第二个文件也不同了。这两个文件都来自同一台计算机。在这两种情况下，源文件最初都有一个数字1，在新文本文件中变为0。



为了进一步测试，我创建了一个多次执行相同步骤的测试应用程序。我为多个文本文件重复了上述过程两次。然后，我通过散列算法运行2个（假设相同的）文本文件，以验证文件是否相同。在大约200次尝试中，它找到了8个不同的文件。



我很震惊因为我从未见过我打算写入硬盘的数据的问题驱动器与实际写入驱动器的驱动器不完全相同。我们检查了计算机上的硬盘驱动器，看起来没问题，所以我们用不同的设备更换了计算机，问题似乎已经解决了。我们仍然没有弄清楚计算机究竟是什么问题。



我尝试过：



此应用程序创建的文本文件是用于驱动切割金属零件的CNC机器的G代码文件。它创建的错误文本文件导致我们废弃2个昂贵的部件。因此，我试图弄清楚我可以在我的应用程序中做些什么来阻止这种情况。我的第一个想法是添加我在我的测试应用程序中所做的相同逻辑，在那里我创建新磁带两次然后比较2个文件是否相等。除了加倍处理时间外，此选项不是100％的错误证明，因为它可以在两个文本文件中复制相同的错误，但仍然与源文本文件不同。有没有人有更好的想法？可以在写完后立即比较每一行吗？我不认为你可以同时读写，因此每次从读到切换时都需要打开和关闭。任何帮助将不胜感激。

I need some advice on how to handle a unique situation with one of my Vb.net apps. This app creates a new text file which is basically a subset of a different text file. The app works as follows:
• Copy source text file from a network drive to the local computers drive
• Open copied source text file for reading
• Open a new text file for writing
• Read source file line #1 and store results in a variable then write what is in the variable to the new text file
• Repeat the above step X times
• Read source text file line by line and search for a line that contains "Y"
• Copy that line to the new text file
• Continue reading the source text file line by line and copying data to the new text file until it finds a line that contains "Z"
• Close both text files
• Move new text file to a different folder

The above code has been running for at least 8 years on 30+ different computers and we have never had an issue until last week. Then last week we noticed out of the blue that one of the new text files was different on 1 line vs. the source file. A few days later, we noticed a 2nd file that was different as well. Both files came from the same computer. In both cases, the source file originally had a digit of "1" that got changed to "0" in the new text file.

In order to test this further, I created a test app that did the same steps multiple times. I repeated the above process twice for multiple text file. I then ran the 2 (supposedly identical) text files through a hashing algorithm to validate the files were identical. Out of approximately 200 attempts, it found 8 files that were different.

I was shocked because I have never seen an issue where the data I intended to write to the hard drive wasn’t exactly the same as what was actually written to the drive. We checked the hard drive on the computer and it appeared to be OK so we replaced the computer with a different unit and the problem has appeared to be resolved. We still haven’t figured out exactly what the issue is with the computer.

What I have tried:

The text files this app creates are G-code files used to drive a CNC machine that cuts metal parts. The bad text files it created caused us to scrap 2 expensive parts. Because of this, I am trying to figure out something I can do in my app that will prevent this. My first thought was to add the same logic I did in my test app where I create the new tape twice and then compare the 2 files for equality. Besides doubling the process time, this option is not 100% error proof because it would be possible to duplicate the same error in both text files and still be different then the source text file. Does anyone have any better ideas? Would it be possible to compare each line immediately after it gets written? I don’t think you can read and write at the same time so this would require opening and closing every time when switching from read to write. Any help would be appreciated.

推荐答案

因为更换系统后问题消失了，这可能是一个硬件问题。可能不仅HD出现故障，还有其他部分，如内存（RAM），CPU，控制器和电缆。它也可能来自电磁辐射（CNC环境通常比办公室辐射更多）。



为了避免因磁盘故障和传输数据而导致的错误数据，你可以做你已经完成的事情：

使用可能是外部（附加文件）的校验和或散列或文件本身的一部分（这对你的文件来说似乎是不可能的）。



另一种选择是在内存中创建完整的新文件内容，将其写入文件，再次读取文件，并与内存中保存的数据进行比较。 br />


但这两种方法都避免了由于磁盘故障导致的数据不一致。



如果你真的需要更好的检查，那么只有一个选项：冗余。

这意味着你必须使用两个（或更多） ）系统，他们自己的文件版本并比较它们。

Because the problem disappeared after replacing the system it was probably a hardware problem. It may be not only the HD that fails, but also other parts like memory (RAM), CPU, controllers, and cables. It may be also sourced by electromagnetic radiation (a CNC environment has usually more radiation than an office).

To avoid wrong data sourced by disk failures and when transferring data, you can do what you have done already:
Use checksums or hashes which may be external (additional files) or part of the file itself (which seems to be not possible for your files).

Another option is creating the complete new file content in memory, write it to the file, read the file in again, and compare with the data held in memory.

But both methods avoid only data inconsistency due to disk failures.

If you really need better checks then there is only one option: Redundancy.
That means that you have to use two (or more) systems that their own versions of the file and compare them.

这篇关于验证写入文本文件的文本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！