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

RE: Filesystem has no such representation

From: Matthew Warneford <Matthew_at_DUBIT.CO.UK>
Date: 2004-05-01 15:14:41 CEST

Hi -

I don't have any repository back ups, ive been testing out subversion for a
few weeks. However because ive been testing it there is no critial work on
there, and all my source code is backed up on my machine.

What sort of situations would cause the database to fail like this?

Running the recover exe produced this out put

db_recover: DB_LOGC->get: LSN 434/1013986: invalid log record header
db_recover: PANIC: Input/output error
db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery

Any thoughts?

Matt

> -----Original Message-----
> From: Max Bowsher [mailto:maxb@ukf.net]
> Sent: 30 April 2004 17:53
> To: Matthew Warneford; users@subversion.tigris.org
> Subject: Re: Filesystem has no such representation
>
> 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
> >
> > E:\development\respository\db\
> >
> > Then tried to run the comman db_recover -c but given the error that the
> name
> > 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.
>
> Go to:
> http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=688
> 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.
>
>
> Max.
>
>
> >> -----Original Message-----
> >> From: Max Bowsher [mailto:maxb@ukf.net]
> >> Sent: 28 April 2004 14:07
> >> To: Matthew Warneford; users@subversion.tigris.org
> >> 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
> >>> goes...
> >>>
> >>> The system has been working brilliantly for a while, however today im
> now
> >>> 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
> be
> >>> great! Im hoping that the work has not been lost?
> >>
> >> Hard to say. The error means that the repository database has been
> >> damaged,
> >> 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
> >> backup,
> >> 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
> >> repository
> >> database available on a web/ftp server somewhere, and I will try to
> >> identify
> >> and repair as much damage as is possible.
> >>
> >> Max.
Received on Sat May 1 15:12:42 2004

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

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