# sample.coldsyncrc # # $Id: sample.coldsync.rc,v 1.5 2001/10/12 02:16:26 arensb Exp $ # # This is an example .coldsyncrc file. It is NOT intended as a working # configuration. It is rather a series of examples. Read it through. # At least glance at it. Then read the manual. ######################################## ### Options block ######################################## # You may specify global options and variables here if you wish. # Useful options are: # CONDUITDIR: a colon separated list of directories, in which conduits may # be found. # LOGFILE: the log file where information is printed. (If none is specified, # logs go to stdandard error.) options { CONDUITDIR: "$(CONDUITDIR):$(HOME)/.palm/conduits"; } ######################################## ### Listen block ######################################## # Your .coldsyncrc should begin with a listen block. This tells # ColdSync which device to listen to, at what speed the sync will # place, and so forth. # If you omit the listen block, ColdSync will substitute defaults. The # following listen block is equivalent to the defaults: listen serial { device: "/dev/palm"; speed: 38400; } # If you're syncing a Visor over USB under FreeBSD, use "usb" instead # of "serial": listen usb { device: "/dev/ugen0"; } # However, if you're syncing a Visor under Linux, and using the "make # the USB bus look like a serial device" hack, you should use "serial" # anyway: listen serial { device: "/dev/ttyUSB1"; } ######################################## ### PDA block ######################################## # If you have more than one Palm, you can sync them to different # directories by declaring PDA blocks. Specify the Palm's serial # number using the "snum" directive, and the directory to sync with # using the "directory" directive: pda "My Palm III" { snum: "189X7M27GA63-N"; directory: "/home/arensb/.palmIII"; } # If your Palm doesn't have a serial number in ROM (e.g., a PalmPilot # or Visor), use the empty string (of course, if you have more than # one such Palm, they'll all use the same PDA block): pda "My PalmPilot Pro" { snum: ""; directory: "/home/arensb/.palmPilot"; } # The 'default' keyword specifies that this PDA block should be used # if no others match. In the following example, the backup directory # for the Palm III will be /home/arensb/.palmIII; the backup directory # for old Palms with no serial number will be /home/arensb/.palmPilot; # and the backup directory for anything else will be # /home/arensb/.allPalms . pda "My Palm III" { snum: "189X7M27GA63-N"; directory: "/home/arensb/.palmIII"; } pda "Default for old PalmPilots" { snum: ""; directory: "/home/arensb/.palmPilot"; default; } pda "Default for everything else" { directory: "/home/arensb/.allPalms"; default; } ######################################## ### Conduits ######################################## # Conduits presently come in three flavors: Fetch, Dump, and Sync. # # Fetch conduits are run before the main sync. They are intended to # gather data from files and create or update the databases with which # ColdSync will then sync. # # Dump conduits run after the main sync. They are intended to convert # the newly-synchronized databases back into whatever form is most # useful on the local machine. # # Sync conduits run during the main portion of the sync, and can run # instead of, or in addition to the built-in generic conduit. They are # intended for cases too complex to be easily handled by Fetch and # Dump conduits. # # Other than that, conduits run in the order in which they appear in # the .coldsyncrc ## Example 0: # If you do not have a .coldsyncrc file, the following is equivalent # to the defaults. It says to run the built-in generic conduit on all # databases unless another one has been specified. conduit sync { path: [generic]; type: */*; default; } ## Example 1: # 'memo-text', when run as a Fetch conduit, converts the file # /home/arensb/Memos into a .pdb file; when run as a Dump conduit, it # converts the .pdb file back into text format in /home/arensb/Memos. conduit fetch, dump { path: "/usr/local/libexec/conduits/memo-text"; type: memo/DATA; arguments: File: /home/arensb/Memos; Delete: no; } ## Example 2: # ColdSync processes databases in apparently-random order. For each # database, however, conduits are run in the order in which they # appear in the .coldsyncrc . Here, "conduit1" will always run before # "conduit2". conduit fetch { path: "/usr/local/libexec/conduits/conduit1"; type: memo/DATA; } conduit fetch { path: "/usr/local/libexec/conduits/conduit2"; type: memo/DATA; } ## Example 3: # The 'default' keyword specifies that a conduit will be run if no # more suitable conduit can be found. In the following example, # 'default-conduit' is a default for all databases. # # When ColdSync runs the Fetch conduits for the Memo application, it # will run 'memo-text', but will not run 'default-conduit' because a # better match has been found. # When ColdSync runs the Fetch conduits for the Address Book # application, it will only run 'default-conduit' because no other # conduit matches. conduit fetch { path: "/usr/local/libexec/conduits/default-conduit"; type: */*; default; } conduit fetch { path: "/usr/local/libexec/conduits/memo-text"; type: memo/DATA; } ## Example 4: # It is possible to specify several default conduits. Only the last # matching conduit will be run, however. # # In this example, ColdSync will run 'default-todo' for all databases # whose creator is "todo" (and will not run 'default-conduit'). It # will run 'default-conduit' for all other databases. conduit fetch { path: "/usr/local/libexec/conduits/default-conduit"; type: */*; default; } conduit fetch { path: "/usr/local/libexec/conduits/default-todo"; type: todo/*; default; } ## Example 5: # The 'final' keyword indicates that no other conduits should be # considered. # In the following example, 'conduit1' and 'conduit2' will be run, but # 'conduit3' will never be run. conduit dump { path: "/usr/local/libexec/conduits/conduit1"; type: todo/DATA; } conduit dump { path: "/usr/local/libexec/conduits/conduit2"; type: todo/DATA; final; } conduit dump { path: "/usr/local/libexec/conduits/conduit3"; type: todo/DATA; } ## Example 6: # If a conduit block does not contain a 'path' statement, it is # effectively a "do-nothing" conduit. This is mainly useful for the # side effects if you want to declare it as 'final'. # # In the following example, 'conduit2' will never be run, for any # database: conduit dump { path: "/usr/local/libexec/conduits/conduit1"; type: todo/DATA; } conduit dump { type: */*; # Applies to all databases final; } conduit dump { path: "/usr/local/libexec/conduits/conduit2"; type: todo/DATA; } ## Example 7: # A conduit also has access to preferences; these are bits of # configuration data that aren't stored in the database being synced. # Each conduit's documentation should say which preferences it is # interested in. conduit sync { path: "/usr/local/libexec/conduits/deliver-mail"; type: mail/DATA; pref: mail/3; # Mail signature preference }