(In reply to comment #0)
> holy cow, that was quite tiresome and utterly frustrating. Four quite
> complex commands to eventually be able to connect to the calendar, then
> another two to eventually make addressbook work. That's not fun.

It would have been possible with two more complex commands (by combining the setup of all sources into one invocation), but I guess that wouldn't have made it easier.

I'm open for suggestions how this could be made simpler. There's a mail thread about that here:
http://comments.gmane.org/gmane.comp.mobile.syncevolution/3992

> And now it doesn't even work and I feel unable to get more useful
> information.
> 
> So here is the problem:
> $ syncevolution --daemon=no --print-items target-config@radicale cards1
> 342F8BEA-54AC0772-04A3D2F6%2evcf
> $ syncevolution --daemon=no  target-config@radicale cards1

You are trying to sync with the "target config". Syncing must be triggered via the "sync" config. In other words, do:
    syncevolution radicale cards1

The reason why you get no useful error output is that the target config looks like a normal SyncML config to SyncEvolution (syncURL set to http:// with username/password available).

As I said in the mail thread, I am not happy with the "target-config" aspect. But the discussion did not reach a conclusion on how it can be avoided.

> $ syncevolution --daemon=no --status target-config@radicale cards1
> [DEBUG 00:00:00] Sun 2012-10-21 19:40:43 UTC = 21:40 +0200 CEST
> [INFO 00:00:00] addressbook: inactive
> [INFO 00:00:00] calendar: inactive
> [INFO 00:00:00] calendar1: inactive
> [INFO 00:00:00] memo: inactive
> [INFO 00:00:00] todo: inactive
> [DEBUG 00:00:00] cards1: using full item scan to detect changes
> syncevolution: /usr/include/boost/smart_ptr/shared_ptr.hpp:424: T*
> boost::shared_ptr<T>::operator->() const [with T = SyncEvo::Neon::Session]:
> Assertion `px != 0' failed.
> Aborted (core dumped)

[...]

> While I may just have set SyncEvolution up wrongly (very possible), I do
> feel that there s a bug somewhere. The crasher ultimately is.
> 
> Anyway, I expected to make it synchronise the via CardDAV, especially since
> the calendar part works.

Hmm, I thought I had fixed the "--status" problem:

commit 3d299422f929a647d33b5dec91d53d77c369bcb6
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Fri Jun 29 08:41:31 2012 +0200

    WebDAV: --status for WebDAV source aborted
    
    The command line --status operation did not complete when applied to a
    CalDAV/CardDAV source. Instead it aborted because the operation took a
    code path where the backend was not fully initialized.

Oh, I see: the very first time a source is used it goes through yet another code path. The downside of trying to minimize requests - many special cases :-(

(In reply to comment #1)
> I'm open for suggestions how this could be made simpler. There's a mail
> thread about that here:
> http://comments.gmane.org/gmane.comp.mobile.syncevolution/3992
> 
Thanks for the hint. And thanks for working on that!
In my dream, it only asks me about the type of data to be synced and the remote and local storage, i.e.
--calendar --local evolution:Personal --remote caldav://foo:bar@baz/user/storage/
or so.

Or better yet, it would auto detect that I have calendar data remotely and select that.

> > And now it doesn't even work and I feel unable to get more useful
> > information.
> > 
> > So here is the problem:
> > $ syncevolution --daemon=no --print-items target-config@radicale cards1
> > 342F8BEA-54AC0772-04A3D2F6%2evcf
> > $ syncevolution --daemon=no  target-config@radicale cards1
> 
> You are trying to sync with the "target config". Syncing must be triggered
> via the "sync" config.
oh. wow. That's all double dutch to me :-\ I read the explanation on the website though. A couple of times. It's just mind blowingly much information.

> In other words, do:
>     syncevolution radicale cards1
> 
Thanks! That seems to do it.

I probably could have gotten suspicious by this line:
> [DEVELOPER 00:00:00] SyncML server account: user1
But then again, that line also appears in other logs (just without the username)


I do get empty vcards, however. On the server side, I hav e the following in the collection:

BEGIN:VCALENDAR
PRODID:-//Radicale//NONSGML Radicale Server//EN
VERSION:2.0
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20121022T084031Z
N:evolution on bigbox;test;frmo;;
FN:test frmo evolution on bigbox
X-EVOLUTION-FILE-AS:evolution on bigbox\, test
X-MOZILLA-HTML:FALSE
UID:3c59174f-d09b-43aa-9eee-26f3740c0ac7
X-RADICALE-NAME:3c59174f-d09b-43aa-9eee-26f3740c0ac7.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20091222T233858Z
N:Mueller;Tobias;;;
FN:Tobias Mueller
X-EVOLUTION-FILE-AS:Mueller\, Tobias
NICKNAME:muelli
UID:13fc9240-91c7-4644-95e1-033729e236cb
X-RADICALE-NAME:13fc9240-91c7-4644-95e1-033729e236cb.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20091222T233858Z
N:Mueller;Tobias;;;
FN:Tobias Mueller
X-EVOLUTION-FILE-AS:Mueller\, Tobias
NICKNAME:muelli
UID:1ec200d5-735b-4d16-a0cd-0bcfb0923fa4
X-RADICALE-NAME:1ec200d5-735b-4d16-a0cd-0bcfb0923fa4.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
URL:
TITLE:
ROLE:
X-EVOLUTION-MANAGER:
X-EVOLUTION-ASSISTANT:
NICKNAME:
X-EVOLUTION-SPOUSE:
NOTE:
FN:test contact
N:contact;test;;;
X-EVOLUTION-FILE-AS:contact\, test
X-EVOLUTION-BLOG-URL:
CALURI:
FBURL:
X-EVOLUTION-VIDEO-URL:
X-MOZILLA-HTML:FALSE
X-RADICALE-NAME:342F8BEA-54AC0772-04A3D2F6.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20091222T233858Z
N:Mueller;Tobias;;;
FN:Tobias Mueller
X-EVOLUTION-FILE-AS:Mueller\, Tobias
NICKNAME:muelli
UID:1e91aa4d-11ca-4580-bc35-2ba170338837
X-RADICALE-NAME:1e91aa4d-11ca-4580-bc35-2ba170338837.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20121022T084031Z
N:evolution on bigbox;test;frmo;;
FN:test frmo evolution on bigbox
X-EVOLUTION-FILE-AS:evolution on bigbox\, test
X-MOZILLA-HTML:FALSE
UID:2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac
X-RADICALE-NAME:2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac.vcf
END:VCARD
BEGIN:VCARD
VERSION:3.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN
REV:20121022T084031Z
N:evolution on bigbox;test;frmo;;
FN:test frmo evolution on bigbox
X-EVOLUTION-FILE-AS:evolution on bigbox\, test
X-MOZILLA-HTML:FALSE
UID:72e42321-92d7-4197-b150-1ee77a370645
X-RADICALE-NAME:72e42321-92d7-4197-b150-1ee77a370645.vcf
END:VCARD
END:VCALENDAR


But locally, I get 6 contacts, four of which are empty. The other two are "test frmo evolution..." and a "Tobias Mueller", but I don't know which (as the above mentioned file contains multiple) :-\




> Oh, I see: the very first time a source is used it goes through yet another
> code path. The downside of trying to minimize requests - many special cases
> :-(

So shall this bug be about tracking that crasher, then?

(In reply to comment #2)
> (In reply to comment #1)
> > I'm open for suggestions how this could be made simpler. There's a mail
> > thread about that here:
> > http://comments.gmane.org/gmane.comp.mobile.syncevolution/3992
> > 
> Thanks for the hint. And thanks for working on that!
> In my dream, it only asks me about the type of data to be synced and the
> remote and local storage, i.e.
> --calendar --local evolution:Personal --remote
> caldav://foo:bar@baz/user/storage/
> or so.
> 
> Or better yet, it would auto detect that I have calendar data remotely and
> select that.

In other words, add a setup wizard mode to the command line. That's doable, but also quite a bit of work.

> > > $ syncevolution --daemon=no  target-config@radicale cards1
> > 
> > You are trying to sync with the "target config". Syncing must be triggered
> > via the "sync" config.
> oh. wow. That's all double dutch to me :-\ I read the explanation on the
> website though. A couple of times. It's just mind blowingly much information.

Did the terminology section help? It should have. If not, I need to reword it.

> I probably could have gotten suspicious by this line:
> > [DEVELOPER 00:00:00] SyncML server account: user1
> But then again, that line also appears in other logs (just without the
> username)

It probably would make sense to add more explicit INFO lines about what SyncEvolution is doing. Before 1.3, such output would have been mixed with normal output (for example, the item content in --export -), therefore SyncEvolution was very quiet. Since 1.3, such messages go to stderr and can be used more liberally. It's just again something that has been done yet.

> I do get empty vcards, however.

The output of
SYNCEVOLUTION_DEBUG=1 syncevolution --daemon-no --export - target-config@radicale cards1

would be useful.

 On the server side, I hav e the following in
> the collection:
> 
> BEGIN:VCALENDAR
> PRODID:-//Radicale//NONSGML Radicale Server//EN
> VERSION:2.0
> BEGIN:VCARD

That looks suspicious. Normally VCARDs are not stored inside VCALENDAR.

> > Oh, I see: the very first time a source is used it goes through yet another
> > code path. The downside of trying to minimize requests - many special cases
> > :-(
> 
> So shall this bug be about tracking that crasher, then?

That, and the empty vCard issue.

(In reply to comment #3)
> In other words, add a setup wizard mode to the command line. That's doable,
> but also quite a bit of work.
> 
Hm. Maybe not exactly a wizard with steps and all. But in the case of CalDAV or CardDAV, it should be possible to check the remote contents for being either calendar, todolist or addressbook data, I think. 

> Did the terminology section help? It should have. If not, I need to reword
> it.
> 
Hm. I don't know. It's just so much text. Every time I read it, I feel it's totally clear. But shortly after that, when trying to interact with SyncEvolution, that feeling is gone and total confusion and frustration kicks in. Many things seem to be implicit and it's not immediately clear what the things are, that I give a name, i.e. "target-config@radicale", "calendar1", "radicale". And if anything goes wrong, the sanest thing to do seems to be to mv ~/.config/syncevolution out of the way, because I find it not discoverable which part failed due to which configuration (and how to change it then). That also adds to the frustration.
I'm just ranting here without any proposal at all. Shame on me. But despite my really unimportant frustration, I do appreciate all your efforts and I am grateful that you really try to make syncing happen (it's 2012 after all...).

Anyway, maybe a picture would help. For various use cases. For me, I would probably appreciate a picture with PC, a "cloud", several databases and the relevant terms attached to them.

> > I do get empty vcards, however.
> 
> The output of
> SYNCEVOLUTION_DEBUG=1 syncevolution --daemon-no --export -
> target-config@radicale cards1
> 
> would be useful.
> 
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --print-items target-config@radicale cards1
[DEBUG 00:00:00] Wed 2012-10-24 10:32:09 UTC = 12:32 +0200 CEST
[DEBUG 00:00:00] using libneon neon 0.29.6: Library build, IPv6, Expat 2.0.1, zlib 1.2.5, GNU TLS 2.12.14. with SSL, ZLIB, IPV6, TS_SSL, I18N
HTTP session to http://${URL}:80 begins.
sess: libproxy #0=direct://
[DEBUG 00:00:00] cards1: slow sync or testing, do full item scan to detect changes
[DEBUG 00:00:00] starting PROPFIND, credentials unverified, deadline in 300.0s
ah_create, for WWW-Authenticate
Running pre_send hooks
[DEBUG 00:00:00] forced sending credentials
Sending request headers:
PROPFIND /muelli/cards/ HTTP/1.1
Keep-Alive: 
Connection: TE, Keep-Alive
TE: trailers
Host: ${URL}
Depth: 1
Content-Length: 141
Content-Type: application/xml
Authorization: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Sending request-line and headers:
Doing DNS lookup on ${URL}...
req: Connecting to ip.ip.ip.ip:80
Sending request body:
Body block (141 bytes):
[<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"><prop>
<getetag xmlns="DAV:"/>
<resourcetype xmlns="DAV:"/>
</prop></propfind>
]
Request sent; retry is 0.
[status-line] < HTTP/1.1 207 Unknown
[hdr] Date: Wed, 24 Oct 2012 10:32:09 GMT
Header Name: [date], Value: [Wed, 24 Oct 2012 10:32:09 GMT]
[hdr] Server: Apache
Header Name: [server], Value: [Apache]
[hdr] DAV: 1, 2, 3, calendar-access, addressbook, extended-mkcol
Header Name: [dav], Value: [1, 2, 3, calendar-access, addressbook, extended-mkcol]
[hdr] Content-Length: 2289
Header Name: [content-length], Value: [2289]
[hdr] Keep-Alive: timeout=15, max=100
Header Name: [keep-alive], Value: [timeout=15, max=100]
[hdr] Connection: Keep-Alive
Header Name: [connection], Value: [Keep-Alive]
[hdr] Content-Type: text/xml
Header Name: [content-type], Value: [text/xml]
[hdr] 
End of headers.
Running post_headers hooks
Reading 2289 bytes of response body.
Got 1160 bytes.
Read block (1160 bytes):
[<?xml version="1.0"?>
<multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <response>
    <href>/muelli/cards/</href>
    <propstat>
      <prop>
        <getetag>"-7768052930791486994"</getetag>
        <resourcetype>
          <C:calendar />
          <collection />
        </resourcetype>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
  <response>
    <href>/muelli/cards/3c59174f-d09b-43aa-9eee-26f3740c0ac7.vcf</href>
    <propstat>
      <prop>
        <getetag>"6142677616598662413"</getetag>
        <resourcetype />
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
  <response>
    <href>/muelli/cards/13fc9240-91c7-4644-95e1-033729e236cb.vcf</href>
    <propstat>
      <prop>
        <getetag>"-793186154807718785"</getetag>
        <resourcetype />
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
  <response>
    <href>/muelli/cards/1ec200d5-735b-4d16-a0cd-0bcfb0923fa4.vcf</href>
    <propstat>
      <prop>
        <getetag>"-7419273146883220427"</getetag>
        <resourcetype />
      </prop>
      <status>HTTP/1.1 200]
[DEBUG 00:00:00] item 3c59174f-d09b-43aa-9eee-26f3740c0ac7.vcf = rev 6142677616598662413
[DEBUG 00:00:00] item 13fc9240-91c7-4644-95e1-033729e236cb.vcf = rev -793186154807718785
Reading 1129 bytes of response body.
Got 1129 bytes.
Read block (1129 bytes):
[ OK</status>
    </propstat>
  </response>
  <response>
    <href>/muelli/cards/342F8BEA-54AC0772-04A3D2F6.vcf</href>
    <propstat>
      <prop>
        <getetag>"6187965458013749004"</getetag>
        <resourcetype />
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
  <response>
    <href>/muelli/cards/1e91aa4d-11ca-4580-bc35-2ba170338837.vcf</href>
    <propstat>
      <prop>
        <getetag>"6030810582171879567"</getetag>
        <resourcetype />
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
  <response>
    <href>/muelli/cards/2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac.vcf</href>
    <propstat>
      <prop>
        <getetag>"-6196304151567771931"</getetag>
        <resourcetype />
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
  <response>
    <href>/muelli/cards/72e42321-92d7-4197-b150-1ee77a370645.vcf</href>
    <propstat>
      <prop>
        <getetag>"3294707919730409193"</getetag>
        <resourcetype />
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
</multistatus>
]
[DEBUG 00:00:00] item 1ec200d5-735b-4d16-a0cd-0bcfb0923fa4.vcf = rev -7419273146883220427
[DEBUG 00:00:00] item 342F8BEA-54AC0772-04A3D2F6.vcf = rev 6187965458013749004
[DEBUG 00:00:00] item 1e91aa4d-11ca-4580-bc35-2ba170338837.vcf = rev 6030810582171879567
[DEBUG 00:00:00] item 2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac.vcf = rev -6196304151567771931
[DEBUG 00:00:00] item 72e42321-92d7-4197-b150-1ee77a370645.vcf = rev 3294707919730409193
Running post_send hooks
ah_post_send (#0), code is 207 (want 401), WWW-Authenticate is (none)
Request ends, status 207 class 2xx, error line:
207 Unknown
[DEBUG 00:00:00] credentials accepted
Running destroy hooks.
Request ends.
13fc9240-91c7-4644-95e1-033729e236cb%2evcf
1e91aa4d-11ca-4580-bc35-2ba170338837%2evcf
1ec200d5-735b-4d16-a0cd-0bcfb0923fa4%2evcf
2e6b0bbb-8e72-45f8-b7a8-4f2d02ef8aac%2evcf
342F8BEA-54AC0772-04A3D2F6%2evcf
3c59174f-d09b-43aa-9eee-26f3740c0ac7%2evcf
72e42321-92d7-4197-b150-1ee77a370645%2evcf
sess: Destroying session.




>  On the server side, I hav e the following in
> > the collection:
> > 
> > BEGIN:VCALENDAR
> > PRODID:-//Radicale//NONSGML Radicale Server//EN
> > VERSION:2.0
> > BEGIN:VCARD
> 
> That looks suspicious. Normally VCARDs are not stored inside VCALENDAR.
> 
uh. interesting. Maybe a radicale bug. Apparently, it's not a very nice Ca{rd,l}DAV server as it doesn't care about standards so much (besides it being *very* slow with a couple of hundred items). But it still seems to be nicest server out there :-\

(In reply to comment #4)
[...]

I'll reply to the usability comments separately (and later - not much time right now).

> > > I do get empty vcards, however.
> > 
> > The output of
> > SYNCEVOLUTION_DEBUG=1 syncevolution --daemon-no --export -
> > target-config@radicale cards1
> > 
> > would be useful.
> > 
> $ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --print-items
> target-config@radicale cards1

That's not quite what I would like to see - please retry with "--export -" instead of "--print-items". The --print-items does not try to get any content data.

> Maybe a radicale bug. Apparently, it's not a very nice
> Ca{rd,l}DAV server as it doesn't care about standards so much (besides it
> being *very* slow with a couple of hundred items). But it still seems to be
> nicest server out there :-\

It's the easiest to set up from scratch. DAViCal is another, a lot more standard-compliant alternative. It installs easily on Debian.

Created attachment 69048 [details]
syncevolution --export -

(In reply to comment #5)
> That's not quite what I would like to see
oups. Faux pas on my side. I didn't read carefully enough. Sorry. The data is attached.

FWIW: I get interesting log messages on the server side whenever I do the export:
Oct 25 01:11:46 hostname grsec: From ip.ip.ip.ip: denied RWX mmap of <anonymous
 mapping> by /usr/sbin/apache2[apache2:3603] uid/euid:500/500 gid/egid:500/5
00, parent /usr/sbin/apache2[apache2:2813] uid/euid:0/0 gid/egid:0/0 

That is a grsec hardened kernel probably complaining about the Python interpreter. Which is weird, because other Python processes do not cause this message. Anyway, the exported vcards look good.

(In reply to comment #6)
> Created attachment 69048 [details]
> syncevolution --export -
> 
> (In reply to comment #5)
> > That's not quite what I would like to see
> oups. Faux pas on my side. I didn't read carefully enough. Sorry. The data
> is attached.

It shows that the server encapsulates the VCARD inside a VCALENDAR, just like it did in its internal storage. That's incorrect and cannot be parsed by SyncEvolution: --export just dumps the data, but syncing needs to parse it and thus fails.

I've no idea why Radicale does this - please bring it up there and report back here.

(In reply to comment #7)
> It shows that the server encapsulates the VCARD inside a VCALENDAR, just
> like it did in its internal storage. That's incorrect and cannot be parsed
> by SyncEvolution: --export just dumps the data, but syncing needs to parse
> it and thus fails.
> 
> I've no idea why Radicale does this - please bring it up there and report
> back here.

hm. I can't reproduce. So while experimenting, I must have made some weird requests or mixed things up. I guess the empty VCards are not a problem then.

(In reply to comment #4)
> (In reply to comment #3)
> > In other words, add a setup wizard mode to the command line. That's doable,
> > but also quite a bit of work.
> > 
> Hm. Maybe not exactly a wizard with steps and all. But in the case of CalDAV
> or CardDAV, it should be possible to check the remote contents for being
> either calendar, todolist or addressbook data, I think.

The command line as it stands today manipulates and uses configs. Any kind of code which helps creating configs for specific use cases is a separate layer, which today doesn't exist in the command line.

I'm unsure how to move forward though. Add that layer for the creation of configs? All other operations then would still expose the user to the details. Or add some high-level config which then gets translated into the actual mode of operation underneath?

> > Did the terminology section help? It should have. If not, I need to reword
> > it.
> > 
> Hm. I don't know. It's just so much text. Every time I read it, I feel it's
> totally clear. But shortly after that, when trying to interact with
> SyncEvolution, that feeling is gone and total confusion and frustration
> kicks in. Many things seem to be implicit and it's not immediately clear
> what the things are, that I give a name, i.e. "target-config@radicale",
> "calendar1", "radicale".

Would a command line syntax that doesn't use positional arguments be better? On the one hand, the current syntax allows very short commands ("syncevolution radicale calendar"). 

On the other hand, combined with the lack of constraints for config names, detecting user errors is hard: "syncevolution --foo bar" uses "--foo" as config name, which is not what the user wanted.

The alternative would be "syncevolution --config radicale --source calendar" where "--source" may be repeated multiple times.

> And if anything goes wrong, the sanest thing to do
> seems to be to mv ~/.config/syncevolution out of the way, because I find it
> not discoverable which part failed due to which configuration (and how to
> change it then). That also adds to the frustration.

Understandable. I try to remedy that by listing individual steps in the HOWTOs (like using the target side in isolation), but it's hard to discover that.

> Anyway, maybe a picture would help. For various use cases. For me, I would
> probably appreciate a picture with PC, a "cloud", several databases and the
> relevant terms attached to them.

Okay. So, who draws one? ;-/

(In reply to comment #2)
> (In reply to comment #1)

> > > $ syncevolution --daemon=no --status target-config@radicale cards1

> > Oh, I see: the very first time a source is used it goes through yet another
> > code path. The downside of trying to minimize requests - many special cases
> > :-(
> 
> So shall this bug be about tracking that crasher, then?

Yep.

I've fixed the abort. While doing it, I realized that "--status target-config@..." cannot really report on the status of the target side of the sync, because nothing in the command line identifies *which* sync is meant to be reported on: the same target config can be used in multiple sync configs, therefore the meta data which tracks changes is attached to the sync config, not the target config.

I know, not obvious, despite being internally consistent :-/

I've opened a feature request for adding more error messages when a target config is used in operations where it makes no sense: bug #57145.

This also includes an error for attempting to sync the target config (as in comment #0).