Error E160016 "... is not a directory in filesystem ..."

[Vincent Lefevre]

I got the following error several times with "svn log" on a file:

svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8'

Why?

A "svn up" (which actually updated nothing) solved the issue.

[Vincent Lefevre]

Post by Vincent Lefevre
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8'
Why?
A "svn up" (which actually updated nothing) solved the issue.

Actually this was via a wrapper script, and I forgot that there was
the argument -rHEAD:1, but I still don't understand. I can reproduce
the problem on another machine (Debian/stable), without the script:

joooj:~p/tcl> svn info
Path: .
Working Copy Root Path: /srv/d_joooj/home/vinc17/wd
URL: svn+ssh://mysvn/perso/tcl
Relative URL: ^/perso/tcl
Repository Root: svn+ssh://mysvn
Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
Revision: 103179
Node Kind: directory
Schedule: normal
Last Changed Author: vinc17/zira
Last Changed Rev: 103087
Last Changed Date: 2017-10-28 02:20:25 +0200 (Sat, 28 Oct 2017)

joooj:~p/tcl> svn info fidelite
Path: fidelite
Name: fidelite
Working Copy Root Path: /srv/d_joooj/home/vinc17/wd
URL: svn+ssh://mysvn/perso/tcl/fidelite
Relative URL: ^/perso/tcl/fidelite
Repository Root: svn+ssh://mysvn
Repository UUID: 99759db8-4ec0-0310-8bf9-df86780d22d8
Revision: 103179
Node Kind: file
Schedule: normal
Last Changed Author: vinc17/zira
Last Changed Rev: 103087
Last Changed Date: 2017-10-28 02:20:25 +0200 (Sat, 28 Oct 2017)
Text Last Updated: 2017-10-28 02:20:43 +0200 (Sat, 28 Oct 2017)
Checksum: 342e6a9d9e633495bf788cf38d9a536eb975ff1d

joooj:~p/tcl> =svn log -rHEAD:1 fidelite
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8'

joooj:~p/tcl> svnversion
103179

[Vincent Lefevre]

Additional information:

svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/***@103183

works, but

svn log -rHEAD:1 svn+ssh://mysvn/perso/tcl/***@103182

yields the error.

r103183 is just a change of the contents of this file (nothing else).

[Vincent Lefevre]

Post by Vincent Lefevre
works, but
yields the error.
r103183 is just a change of the contents of this file (nothing else).

Even simpler:

joooj% svn ls -r103182 file:///srv/d_joooj/home/svn/root/perso/tcl/***@103182
fidelite
joooj% svn ls -r103183 file:///srv/d_joooj/home/svn/root/perso/tcl/***@103183
fidelite
joooj% svn ls -r103183 file:///srv/d_joooj/home/svn/root/perso/tcl/***@103182
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8'
joooj% svn ls -r103182 file:///srv/d_joooj/home/svn/root/perso/tcl/***@103183
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8'

Ditto between r103181 and r103182, while the commit r103182 occurred on
an unrelated path.

So, it seems that for this file, if the operative revision is different
from the peg revision, this doesn't work. This is not what is described
at http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html and not
the behavior I can observe on the other files, even in the same
directory. So, this seems to be a bug.

Note: "svnadmin verify /srv/d_joooj/home/svn/root" did not find any
issue.

FYI, this is a Debian/stable (stretch) machine, with:

svn, version 1.9.5 (r1770682)
compiled Aug 9 2017, 03:04:58 on x86_64-pc-linux-gnu

Copyright (C) 2016 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- using serf 1.3.9 (compiled with 1.3.9)
- handles 'http' scheme
- handles 'https' scheme

The following authentication credential caches are available:

* Plaintext cache in /srv/d_joooj/home/vinc17/.subversion
* Gnome Keyring
* GPG-Agent
* KWallet (KDE)

[Johan Corveleyn]

Post by Vincent Lefevre

Post by Vincent Lefevre
works, but
yields the error.
r103183 is just a change of the contents of this file (nothing else).

fidelite
fidelite
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8'
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8'
Ditto between r103181 and r103182, while the commit r103182 occurred on
an unrelated path.
So, it seems that for this file, if the operative revision is different
from the peg revision, this doesn't work. This is not what is described
at http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html and not
the behavior I can observe on the other files, even in the same
directory. So, this seems to be a bug.
Note: "svnadmin verify /srv/d_joooj/home/svn/root" did not find any
issue.
svn, version 1.9.5 (r1770682)
compiled Aug 9 2017, 03:04:58 on x86_64-pc-linux-gnu

Most likely, /perso/***@103182 is not the same node as
/perso/***@103183 and /perso/***@103181. I suppose you should be able
to see this in the history, with an 'svn log -v' of the root
directory: 103182 should show an 'R' for /perso/tcl, meaning it was
Replaced by another node, not historically related to /perso/tcl
before. And 103183 replaced it again with a copy of the original node.

That would mean that the node with path /perso/tcl in r103182 is
different from the one before and after it. So /perso/***@103183 does
not exist in 103182. Could that be the case?

If so, it's possible that this is working as designed.

[Vincent Lefevre]

Post by Johan Corveleyn
to see this in the history, with an 'svn log -v' of the root
directory: 103182 should show an 'R' for /perso/tcl, meaning it was
Replaced by another node, not historically related to /perso/tcl
before. And 103183 replaced it again with a copy of the original node.

No, there's no such thing. This directory was created in r99807,
and the only changes were on the file "fidelite".

[Daniel Shahaf]

Post by Vincent Lefevre
works, but
yields the error.
r103183 is just a change of the contents of this file (nothing else).

How did you determine this?

Please show the output of 'svn log -qvr103183 ^/'. Are there any authz
read restrictions in effect?

[Vincent Lefevre]

Post by Daniel Shahaf

Post by Vincent Lefevre
works, but
yields the error.
r103183 is just a change of the contents of this file (nothing else).

How did you determine this?

svn log -v on the root and on perso/tcl.

Note also that this is my personal repository, and I know what I did.

Post by Daniel Shahaf
Please show the output of 'svn log -qvr103183 ^/'.

joooj:~/wd> svn log -qvr103183 '^/'
------------------------------------------------------------------------
r103183 | vinc17/zira | 2017-11-01 00:35:54 +0100 (Wed, 01 Nov 2017)
Changed paths:
M /perso/tcl/fidelite
------------------------------------------------------------------------

Post by Daniel Shahaf
Are there any authz read restrictions in effect?

No restrictions.

[Vincent Lefevre]

Also, this is not consistent, unless future commits have an influence
on the following command:

joooj:~> svn ls -r99809 file:///srv/d_joooj/home/svn/root/perso/tcl/***@99808
svn: E160016: Failure opening '/perso/tcl/fidelite'
svn: E160016: '/perso/tcl' is not a directory in filesystem '99759db8-4ec0-0310-8bf9-df86780d22d8'

ioooi:~> svn ls -r99809 file:///srv/d_ioooi/home/svn/root/perso/tcl/***@99808
fidelite

FYI, ioooi is the old server, which I migrated with dump+load to
joooj at revision r102683. So, I should have obtained the same
result; the one given by ioooi is the expected one.