0

I've been thinking about writing a small specialized backup app, similar to newly introduced file history in Windows 8. The basic idea is to scan some directories every N hours for changed files and copy them to another volume. The problem is, some other apps may request access to these files while they are being backed up and get an access denial, potentially causing all kinds of nasty problems.

I far as i can tell, there are several approaches to that problem:

1) Using Volume Shadow Copy service

From my point of view, the future of this thing is uncertain and it's overhead during heavy IO loads may cripple the system.

2) Using Sharing Mode when opening files

Something like this mostly works...

using (var stream = new FileStream("test.txt", FileMode.Open, FileAccess.Read,
    FileShare.Delete | FileShare.ReadWrite | FileShare.Read | FileShare.Write))
{
    [Copy data]
}

... until some other process request access to the same file without FileShare.Read, at which point an IOException will be thrown.

3) Using Opportunistic Lock that may be "broken" by other (write?) requests.

This behaviour of FileIO.ReadTextAsync looks exactly like what I want, but it also looks very implementation-specific and may be changed in the future. Does someone knows, how to explicitly oplock a file locally via C# or C++?

Maybe there is some simple C# method like File.TryReadBytes that provides such "polite" reading? I'm interested in the solutions that will work on Windows 7 and above.

Community
  • 1
  • 1
user49275
  • 3
  • 1
  • Do you understand the issues involved in backing up a file system that is not quiescent or shadowed? That applications don't make atomic updates to files? That related files may be saved in an inconsistent state? This might be a bad idea. – HABO Jan 01 '15 at 17:23
  • @HABO It depends. In case of big databases with high connectivity and frequent updates it will indeed be a horrible idea, but in case of a large storage of unrelated and mostly static files few potential inconsistencies will usually be isolated and therefore not a deal breaker. I'm concerned only with the later case. – user49275 Jan 01 '15 at 18:09
  • OpLocks are a network feature, not a local feature. You're also missing another point, I believe: your app may either be the first or the second to request a lock. Both cases can cause problems, but if you're first then the other program will encounter an IO exception. – MSalters Jan 02 '15 at 02:04

1 Answers1

1

My vote's on VSS. The main reason is that it doesn't interfere with other processes modifying your files, thus it provides consistency. A possible inconsistency pretty much defeats the purpose of a backup. The API is stable and I wouldn't worry about its future.

fejesjoco
  • 11,763
  • 3
  • 35
  • 65
  • I'm concerned with the case of a large storage of unrelated and mostly static files. Inconsistencies won't break the whole thing and having 99.9% restored is usually good enough. I imagine that file history was made just for such occasion, only without some features I would like to have. – user49275 Jan 01 '15 at 18:25