Matthew Warneford wrote:
> Hi -
> Thanks for the quick reply!
> Im trying to run 'db_recover -c' from the command line but having
> problems... am I making a school boy error here?
> Ive navigated to
> Then tried to run the comman db_recover -c but given the error that the
> specified is not recognised as na internal or....
> Any thoughts?
Ah. Windows. OK.
On Unixy systems the BDB command line tools are almost always installed. On
Windows, they are not.
and get db-4.2.52-win32.zip
That contains, amongst other things, a db_recover.exe you can use.
Also, please tell us:
Do you have a backup?
If so, what is the highest numbered db log file in the backup.
What is the lowest numbered db log file in the active repository?
If there is a log file with the same number as the highest in the backup, in
the active repository, then edit DB_CONFIG immediately, commenting out
"set_flags DB_LOG_AUTOREMOVE", to avoid BDB deleting the logfile if it
becomes unused, because having a full set of log files since the last backup
offers another recovery possibility.
>> -----Original Message-----
>> From: Max Bowsher [mailto:firstname.lastname@example.org]
>> Sent: 28 April 2004 14:07
>> To: Matthew Warneford; email@example.com
>> Subject: Re: Filesystem has no such representation
>> Matthew Warneford wrote:
>>> Hi -
>>> Im not sure if this is the correct place to post this question, but here
>>> The system has been working brilliantly for a while, however today im
>>> getting this error
>>> list -r HEAD svn://server/repository
>>> Filesystem has no such representation
>>> svn: No such representation '8r0'
>>> I don't know if this rings any bells with anyone, any suggestions would
>>> great! Im hoping that the work has not been lost?
>> Hard to say. The error means that the repository database has been
>> and somehow contains a reference to data which is not present.
>> First thing to try is 'svnadmin recover', though I don't think that will
>> help here.
>> Next, try making a *copy* of your repository, changing to the 'db'
>> subdirectory, and running 'db_recover -c'.
>> If that doesn't work, then the remaining options are a restory from
>> possibly using the db/log.* files from the broken repository to bring the
>> backup repository up-to-date, or making Berkeley DB dumps of the
>> database available on a web/ftp server somewhere, and I will try to
>> and repair as much damage as is possible.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Apr 30 18:54:14 2004