[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] Severe database corruption when running without standard file descriptors on unix

From: Tobias Ringström <tobias_at_ringstrom.mine.nu>
Date: 2004-09-03 17:35:29 CEST

A user approached us on IRC today with a severely broken repository. The
problem was that a backup script was running "svnadmin dump" with it's
standard input and standard error file descriptors closed. When BDB
opened the nodes db, the file handle was 2, so when svnadmin printed
it's status output to stderr, the output ended up in the nodes db file,
which of course caused severe database corruption.

It is arguable whether this is a bug in svnadmin or not, but it's pretty
easy to fix, and given the severity of the corruption, I think we should
fix it and also backport it to 1.0.x and 1.1.x. The obvious solution is
to check if file descriptors 0, 1 and 2 are closed, and make them point
to /dev/null if they are. Attached to this email is a patch that
implements this solution for all our command line tools, but there is a
problem with the patch in that it's using #ifndef WIN32. The correct
thing to do is of course to test for features instead of testing what
platform it is not.

The patch uses a few unix specific include files, lstat(), open() and
"/dev/null". What is the correct way to do handle this with autoconf?
Should one check for all these one by one, or all of them? Any help is


Prevent severe database corruption and other horrors on unix systems
if e.g. svnadmin is run with it's standard input, standard output or
standard error file descriptors closed.

* subversion/libsvn_subr/cmdline.c
  (svn_cmdline_init): Open '/dev/null' for standard input, output and
  error if they are closed.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Fri Sep 3 17:35:40 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.