Branko Čibej wrote on Fri, Mar 01, 2019 at 12:08:41 +0100:
> On 01.03.2019 11:53, Stefan Sperling wrote:
> > On Thu, Feb 28, 2019 at 10:44:25PM +0100, Denis Excoffier wrote:
> >> Hello,
> >>
> >> The situation of the replacement of a directory by a circular symlink
> >> generates an XML fragment which is invalid, hence triggers a failure
> >> within the calling system. See hereafter the recipe.
> >>
> >> Starting from a clean folder, do the following:
> >>
> >> % svn mkdir 1
> >> A 1
> >> % rmdir 1
> >> % ln -s 1 1
> >> % touch 2
> >> % svn status --xml
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <status>
> >> <target
> >> path=".">
> >> <entry
> >> path="1">
> >> <wc-status
> >> item="obstructed"
> >> revision="-1"
> >> props="none">
> >> </wc-status>
> >> </entry>
> >> svn: E000062: Can't open directory '/Users/dexco/svntest/svn/1': Too many levels of symbolic links
> >> %
> >>
> >> There is a missing end tag for <target> and <status>.
> >> Another issue is missing output: path '2' is not listed.
> >>
> >> The correction of these issues will be much appreciated (i use 1.11.1).
> >>
> >> Regards,
> >>
> >> Denis Excoffier.
> > Hi Denis,
> >
> > This problem is not specific to symbolic links.
> > There are quite a few cases where --xml produces invalid XML
> > when it runs into some kind of error. Perhaps the command
> > line client should be fixed to close open XML tags when an
> > error occurs, though this also risks people or scripts not
> > noticing such errors.
> >
> > I suppose that, ideally, our XML output would embed errors
> > inside the XML stream in a well-defined manner, as well as
> > printing errors on stderr.
> >
> > So fixing this would require some non-trivial amount of effort.
> > Would you have time and skills to work on this issue?
>
> My advice is to leave well enough alone. Any callers of our tools
> _should_ check the exit code before assuming that the output is valid.
> Just streaming the output through a SAX parser isn't the best strategy.
But there could have been tens of modified or unversioned <entry>s
before the circular symlink. The size of output is O(N) where N is the
number of interesting items found in the wc walk (= the number of lines
in the non-XML `svn st` output). Internally we always process trees
streamily; shouldn't we assume API consumers process trees streamily too?
Secondly, I don't understand why there's an error at all. Shouldn't it
just report an obstruction (dirent's svn_kind_t value changed) and move on?
Cheers,
Daniel
Received on 2019-03-02 01:30:23 CET