10:21 a.m.
https://bugs.freedesktop.org/show_bug.cgi?id=75274
Priority: medium
Bug ID: 75274
CC: syncevolution-issues(a)syncevolution.org
Assignee: syncevolution-issues(a)syncevolution.org
Summary: Removed configurations reappear
Severity: normal
Classification: Unclassified
OS: All
Reporter: g+syncevolution(a)cobb.uk.net
Hardware: Other
Status: NEW
Version: 1.4
Component: SyncEvolution
Product: SyncEvolution
If a configuration for a peer is removed and then is recreated with one source,
all the sources reappear. There seems to be no way to really remove a config
and start again from scratch.
To reproduce:
syncevolution --configure --template none backend=file database=file:///tmp/
databaseformat=text/calendar a@b s1
syncevolution --configure --template none backend=file database=file:///tmp/
databaseformat=text/calendar a@b s2
syncevolution --print-config a@b | grep ^\\[
syncevolution --remove a@b
syncevolution --configure --template none backend=file database=file:///tmp/
databaseformat=text/calendar a@b s1
syncevolution --print-config a@b | grep ^\\[
Both s1 and s2 appear in the final output, whereas only s1 should. I haven't
checked but it may also be that attributes for the new s1 are defaulting to the
values of the old s1.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
11:24 a.m.
New subject: [Bug 75274] Removed configurations reappear
https://bugs.freedesktop.org/show_bug.cgi?id=75274
Patrick Ohly <patrick.ohly(a)gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
This is consistent with the configuration design. Have a look at the man page,
in particular the glossary, and what that says about shared config properties.
Let me explain:
syncevolution --configure --template none backend=file database=file:///tmp/
databaseformat=text/calendar a@b s1
This command does two things:
1. it creates a source config "s1" in context "@b"
2. it creates a sync config "a" in context "@b"
"--remove a@b" only removes the sync config and the per-specific properties of
"s1" (like "sync") - actually in this case, no such per-specific
properties
were used, so only "a" gets removed and backend/database/databaseformat are all
left unchanged.
This is intentional. The goal is to configure sources separately from peers
using the sources. When adding new peers in a context, it automatically has
access to all sources configured in that context. To avoid that, use a new
context or remove the context first.
The latter is probably what you want: "--remove @b".
This removes all properties of s1 and s2.
Does that explain it?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
4:13 p.m.
New subject: [Bug 75274] Removed configurations reappear
https://bugs.freedesktop.org/show_bug.cgi?id=75274
--- Comment #2 from Graham Cobb <g+syncevolution(a)cobb.uk.net> ---
Ah. I understand.
Does "--remove @b" remove all the sync configs (and all the peer-specific
attributes) as well as all the source configs for b?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
2:04 a.m.
New subject: [Bug 75274] Removed configurations reappear
https://bugs.freedesktop.org/show_bug.cgi?id=75274
Patrick Ohly <patrick.ohly(a)gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |NOTABUG
--- Comment #3 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to comment #2)
Ah. I understand.
Does "--remove @b" remove all the sync configs (and all the peer-specific
attributes) as well as all the source configs for b?
Yes, that's how it should work.
I'm closing the issue now. Please reopen if you think something doesn't work
right or needs to be changed.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
2600
days inactive
2613
days old
syncevolution-issues@syncevolution.org
3 comments
1 participants
participants (1)
-
bugzilla-daemon＠freedesktop.org