Bug 52762 - file backend: create items with file suffix
Summary: file backend: create items with file suffix
Status: RESOLVED MOVED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: SyncEvolution (show other bugs)
Version: unspecified
Hardware: All All
: low enhancement
Assignee: SyncEvolution Community
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-19 20:00 UTC by SyncEvolution Community
Modified: 2018-10-13 12:40 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Patrick Ohly 2012-07-29 18:36:00 UTC


---- Reported by jingke.zhang@intel.com 2010-04-19 20:00:58 +0000 ----

This is from http://bugzilla.moblin.org/show_bug.cgi?id=8146

   Description  From  ferdinand   2009-11-23 08:45:06 PST   (-) [reply]

# Files in one directory = file
#    Stores items in one directory as one file per item.
#    The directory is selected via [file://]<path>; it
#    will only be created if the prefix is given, otherwise
#    it must exist already. Only items of the same type can
#    be synchronized and this type must be specified explicitly
#    with both mime type and version.
#    Examples:
#       file:text/plain:1.0
#       file:text/x-vcard:2.1
#       file:text/vcard:3.0
#       file:text/x-calendar:1.0
#       file:text/calendar:2.0
#
# Currently inactive:
# SQLite Address Book = addressbook = contacts = sqlite-contacts
#    vCard 2.1 (default) = text/x-vcard
# Mac OS X or iPhone Address Book = addressbook = contacts = apple-contacts
#    vCard 2.1 (default) = text/x-vcard
#    vCard 3.0 = text/vcard
type = addressbook:text/vcard
#type = file://home/gass/.syncevolution/addressbook:text/vcard:3.0

how is the syntax for storing items in one directory as one file per item. ?
IMHO it does not work as described (last line ) or do I missread ?

------- Comment #1 From pohly 2009-11-26 00:47:35 PST (-) [reply] -------

(In reply to comment #0)
> # Files in one directory = file
> #    Stores items in one directory as one file per item.
> #    The directory is selected via [file://]<path>; it
[...]
> #type = file://home/gass/.syncevolution/addressbook:text/vcard:3.0

I think there's one slash missing at the beginning. The prefix is file:// and
the path is /home/gass/..., so the type becomes:
type = file:///home/gass/.syncevolution/addressbook:text/vcard:3.0

> how is the syntax for storing items in one directory as one file per item. ?
> IMHO it does not work as described (last line ) or do I missread ?

Does it work now? The examples should be updated to include an absolute
path.

------- Comment #2 From ferdinand 2009-12-06 05:07:46 PST (-) [reply] -------

no - it seems to ignore the path
[2009-12-06 14:03:55.468] addressbook: : No such file or directory

------- Comment #3 From pohly 2009-12-06 08:18:48 PST (-) [reply] -------

(In reply to comment #2)
> no - it seems to ignore the path
> [2009-12-06 14:03:55.468] addressbook: : No such file or directory

Hmm, wait. There's something wrong in the comment for "type". The path is not
configured via "type", it must go into "evolutionsource". This should work:

type=file:text/vcard:3.0
evolutionsource=file:///tmp/test_dir

With file:// in evolutinsource, the /tmp/test_dir is created by SyncEvolution.
With just "evolutionsource=/tmp/test_dir", the directory must exist already.

How many attempts do I have before you give up? ;-} Sorry for the confusion.

------- Comment #4 From ferdinand 2009-12-07 02:03:13 PST (-) [reply] -------

:-)
it works as suggested

just one questions
the vcard files do not have an extension .vcf , just numbers

this is OK for Kaddressbook 4.3.4 but might be a problem for programs using
extension to identify the content

------- Comment #5 From pohly 2009-12-07 03:51:22 PST (-) [reply] -------

(In reply to comment #4)
> :-)
> it works as suggested
> 
> just one questions
> the vcard files do not have an extension .vcf , just numbers
> 
> this is OK for Kaddressbook 4.3.4 but might be a problem for programs using
> extension to identify the content

This is a missing feature. Right now, the file backend has no knowledge of the
desired file suffix for the type selected via "type".

Should we add a hard-coded mapping? This would work for all current use cases
("normal" PIM data) without making the configuration more complex.

------- Comment #6 From ferdinand 2009-12-09 01:15:04 PST (-) [reply] -------

Should we add a hard-coded mapping?

IMHO yes

------- Comment #7 From pohly 2009-12-09 04:28:31 PST (-) [reply] -------

I've fixed the comments for "type":

   Files in one directory = file
      Stores items in one directory as one file per item.
      The directory is selected via evolutionsource=[file://]<path>.
      It will only be created if the prefix is given, otherwise
      it must exist already. Only items of the same type can
      be synchronized and this type must be specified explicitly
      with both mime type and version.
      Examples for type:
         file:text/plain:1.0
         file:text/x-vcard:2.1
         file:text/vcard:3.0
         file:text/x-calendar:1.0
         file:text/calendar:2.0
      Examples for evolutionsource:
         /home/joe/datadir - directory must exist
         file:///tmp/scratch - directory is created


(In reply to comment #6)
> Should we add a hard-coded mapping?
> 
> IMHO yes

Okay, recording it as a feature request. However, it is of fairly low priority
right.

Some additional requirements:
- File names are used as they are as local IDs.
  Because users are allowed to add files with
  arbitrary file names, we should preserve that
  instead of trying to strip a file suffix.
- Only new items can get the suffix, not updated
  ones, because those must preserve their existing
  local ID (= file name).



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 1012 at https://bugs.meego.com/show_bug.cgi?id=1012
Comment 1 GitLab Migration User 2018-10-13 12:40:41 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/46.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.