Badly Corrupted Repository: whole file/folder vanished and reappeared at a different locaton even "in history!".

Hi,

the short story (revision 2):

apache2 was restarted during a change. the DB got corrupted.
after db-recovering the working dir a whole folder content
appearad in the wrong folder.
even the whole folder history was incorrectly
"linked" there.

please get it right:
even svn update back to "revision 27" (the initial revision of these files)
still kept the files appear at that incorrect directory.

the long story (revision 2):

clients: WindowsXP, TortoiseSVN-1.0.0 and svn-1.0.0
server: Suse Linux, SVN-1.0.0, Apache2/WebDAV

Note: don't blame it on TortoiseSVN. you can't
blame the used client for a corrupted history in the DB, can you?

I think I was just deleting a _file_, using TortoiseSVN's
Repo Browser function, when our Administrator
restarted the Apache2 on the SVN-TestServer.
TortoiseSVN stopped responding for a long time so i
aborted it.
When the server was up again i got a "500 server error"
when trying to access the repository. The reason behind
this strange errormessage from SVN was a "DB error".
In the Apache2 log I found these messages:
>>
  [Fri Feb 27 12:07:39 2004] [warn] child process 22569 still did not exit, sending a SIGTERM
  ... (reboot of the server, various boot messages )
  [Fri Feb 27 12:07:44 2004] [error] [client 192.168.81.224] (20014)Error string not specified yet: Berkeley DB error while opening environment for filesystem /data/svn/db: DB_RUNRECOVERY: Fatal error, run database recovery
<<

I ensured that no other reason like wrong permissions or configs caused this error
and nobody accessed the svn, then ran the svn recovery:
>>
  svn@CVS:/data/svn> svnadmin recover /data/svn
        Recovery completed.
        The latest repos revision is 32.
<<

from the svn logs i found out that revision 32 was a file commit about an hour
before the Apache reboot happened. so my file delete was probably (atomic, correctly)
not recordet.

BUT then happened something weird:

When i next ran a TortoiseSVN "update" on my working dir (at rev 31 before)
the update process removed a complete folder and its content ("del")...
just to let all the folder contents (consisting of files AND other folders)
reappear ("add") two folders (think of "../..") below the position where
it originally was, with the folder contents added to the previous content
of that folder. The folder content was not "moved" there like on a usual
folder move operation but was completely downloaded from the server again
(as if it was a new import).

It seems to me that all the files got incorrectly "hardlinked" to the wrong
directory ID.
checking out previous revisions (30,29,28,27) did not change anything,
the files stayed in the wrong folder. (I guess even tagged/branched versions
would appear in that incorrect folder, but unfortunately the folder had
no tag/branch to verify that).
The log files indicate that all files still are at "rev.27 - Initial Import",
nobody ever touched them since their first import. They just got "DB corrupted"
to the wrong directory.

maybe a "svnadmin dump" would give a clue to what happened, but unfortunately
the repository has 300MB and the dump has a size of about 1.5 GigBytes...
does the dumpfile contain whole copys of every revision instead of incremental
patches??? It seems the dump will grow beyond good for large repositories
with _many_ _tiny_ changes on _large_ files!

I hope somebody can reproduce what happened and fix it.
before an important repository vanishes into the DB void...

---
  ( this maybe belongs to the TSVN mailing list:
  a funny sideeffect now is, that the -file- I tried to delete that time keeps to
  reappear as a "folder" in the TSVN Repo-Browser. but there never was a
  folder with that name. )
--
======
c.a.t.
>> ------- Additional comments from sussman@tigris.org Fri Feb 27 07:42:39 -0800 2004 -------
>> The issuetracker is not a tech support forum.  There's no clear bug here, and we
>> only file bugs after developers a certain that you've discovered one.  Your
>> whole description sounds like you simply need some tech support or de-confusing.
>> This is why we have the users@ list, and why our big yellow box on the front of
>> the issuetracker explicitly asks people not to post issues without talking to
>> the mailing lists first.  :-)
>> So I'm closing as INVALID.  Please post all your information to users@, and
>> folks will help you out.
>thanks for the fast response, i'll go and post it there, BUT
>please don't underestimate this bug so easily.
>i assure you this IS a "clear bug" as you call it.
>
>or how else could files move "in history" and across
>a few folders just by running svnadmin recover???
>
>svn has a LONG way to go and it will certainly NOT go it
>by moving serious errors to INVALID without thinking a minute.
>
>====
>c.a.t.