Home/ Questions/Q 8961995
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T16:01:30+00:00

I have multiple Windows programs (running on Windows 2000, XP and 7), which handle

  • 0

I have multiple Windows programs (running on Windows 2000, XP and 7), which handle text files of different formats (csv, tsv, ini and xml). It is very important not to corrupt the content of these files during file IO. Every file should be safely accessible by multiple programs concurrently, and should be resistant to system crashes. This SO answer suggests using an in-process database, so I’m considering to use the Microsoft Jet Database Engine, which is able to handle delimited text files (csv, tsv), and supports transactions. I used Jet before, but I don’t know whether Jet transactions really tolerate unexpected crashes or shutdowns in the commit phase, and I don’t know what to do with non-delimited text files (ini, xml). I don’t think it’s a good idea to try to implement fully ACIDic file IO by hand.

What is the best way to implement transactional handling of text files on Windows? I have to be able to do this in both Delphi and C#.

Thank you for your help in advance.

EDIT

Let’s see an example based on @SirRufo’s idea. Forget about concurrency for a second, and let’s concentrate on crash tolerance.

  1. I read the contents of a file into a data structure in order to modify some fields. When I’m in the process of writing the modified data back into the file, the system can crash.

  2. File corruption can be avoided if I never write the data back into the original file. This can be easily achieved by creating a new file, with a timestamp in the filename every time a modification is saved. But this is not enough: the original file will stay intact, but the newly written one may be corrupt.

  3. I can solve this by putting a “0” character after the timestamp, which would mean that the file hasn’t been validated. I would end the writing process by a validation step: I would read the new file, compare its contents to the in-memory structure I’m trying to save, and if they are the same, then change the flag to “1”. Each time the program has to read the file, it chooses the newest version by comparing the timestamps in the filename. Only the latest version must be kept, older versions can be deleted.

  4. Concurrency could be handled by waiting on a named mutex before reading or writing the file. When a program gains access to the file, it must start with checking the list of filenames. If it wants to read the file, it will read the newest version. On the other hand, writing can be started only if there is no version newer than the one read last time.

This is a rough, oversimplified, and inefficient approach, but it shows what I’m thinking about. Writing files is unsafe, but maybe there are simple tricks like the one above which can help to avoid file corruption.

UPDATE

Open-source solutions, written in Java:

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    How about using NTFS file streams? Write multiple named(numbered/timestamped) streams to the same Filename. Every version could be stored in a different stream but is actually stored in the same “file” or bunch of files, preserving the data and providing a roll-back mechanism…
    when you reach a point of certainty delete some of the previous streams.

    Introduced in NT 4? It covers all versions. Should be crash proof you will always have the previous version/stream plus the original to recover / roll-back to.

    Just a late night thought.

    http://msdn.microsoft.com/en-gb/library/windows/desktop/aa364404%28v=vs.85%29.aspx

    • 0