On Mon, Jul 08, 2019 at 05:51:20PM +0200, Thorsten Schöning wrote:
> Hi all,
>
> I recently set up a new Synology NAs and tried to version some custom
> scripts. While some SVN client was already available and checking out
> an empty directory worked as expected, adding some file to the working
> copy didn't. There wasn't any error by default, it seemed that adding
> was successful, but it wasn't, instead the working copy was locked.
>
> > svn add dasikomp_buero_hm
> > svn st
>
> > L .
> > ? @eaDir
> > ? dasikomp_buero_hm
> [...]
>
> Explicitly asking for the last error showed the problem:
>
> > svn add %f && echo $@
> > sh: line 1: 20166 Aborted (core dumped) svn add "test.txt"
>
> Making strace available[1] lead to the root cause being the file
> magic.mgc not found in usual places:
>
> > strace svn add %f
> [...]
> > stat("/root/.magic.mgc", 0x7fff5f129370) = -1 ENOENT (No such file or directory)
> > stat("/root/.magic", 0x7fff5f129370) = -1 ENOENT (No such file or directory)
> > access("/opt/share/misc/magic.mime.mgc", R_OK) = -1 ENOENT (No such file or directory)
> > open("/opt/share/misc/magic.mgc", O_RDONLY) = -1 ENOENT (No such file or directory)
> > rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
> > tgkill(21192, 21192, SIGABRT) = 0
> > --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=21192, si_uid=0} ---
>
> Instead, the file was placed in the following path, which is a symlink
> only as well:
>
> > /usr/share/file/misc/magic.mgc -> /var/packages/DiagnosisTool/target/usr/share/file/misc/magic.mgc
>
> The link target is part of DiagnosisTools, which is interesting
> because that's exactly what has been installed using [1] to make
> strace available. Without that package I didn't find any other
> suitable file on the NAS.
>
> Some things coming into my mind:
>
> 1. Should "svn add" really crash silently?
No, of course it should not ;)
> 2. Should the symlink be recognized and tried like the other pathes?
> 3. Is path handling even something SVN cares about on it's own vs.
> libmagic or else?
I believe this is handled internally by libmagic. SVN has no
idea where the magic database file is and how it gets loaded.
SVN only calls the magic_open() function provided by libmagic.
It checks the return value and skips mime-type detection via
libmagic if an error occurs. I believe that, at the time, this
code was tested with and without a magic database file and both
cases worked. But I don't think we have regression tests for this...
> The installed SVN-client:
>
> > svn, version 1.9.7 (r1800392)
> > compiled Jan 11 2018, 08:42:15 on x86_64-openwrt-linux-gnu
>
> Is that worth filing a bug or fixed or known or ...? Thanks!
If possible please try to reproduce with a newer version.
However, this code hasn't been changed in years so I doubt you
will see different behaviour.
Your best next step is to pin down the exact location of the
crash with a debugger (either live or with a core file).
Is SVN crashing or is libmagic crashing?
Thanks,
Stefan
Received on 2019-07-08 18:10:34 CEST