[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[coldsync-hackers] Newbie question
Sorry to bother you hackers with an end-user question but... I have RH
7.1 on IBM thinkpd a21p, coldsync 2.1.3 succesfully compiled and installed.
My .palmrc is attached to this mail.
laurent is the name of my Palm m505 profile
usb is the user name of the account I use to synchronize, /home/usb its
home directory.
When i start coldsync, if the hotsync has not been pressed on the Palm,
it sleeps. When the hotsync button is pressed, it asks me to do so
....and when I do, nothing happens.
what did I miss ?
here is my /var/log/messages :
Oct 22 13:24:40 skohorod kernel: Manufacturer: Palm, Inc.
Oct 22 13:24:40 skohorod kernel: Product: Palm Handheld
Oct 22 13:24:40 skohorod kernel: SerialNumber: L0PK15J1A166
Oct 22 13:24:40 skohorod kernel: usbserial.c: Sony Clie 4.0 converter
detected
Oct 22 13:24:41 skohorod kernel: visor.c: Sony Clie 4.0: Number of ports: 2
Oct 22 13:24:41 skohorod kernel: visor.c: Sony Clie 4.0: port 1, is for
Generic use and is bound to ttyUSB0
Oct 22 13:24:41 skohorod kernel: visor.c: Sony Clie 4.0: port 2, is for
HotSync use and is bound to ttyUSB1
Oct 22 13:24:41 skohorod kernel: usbserial.c: Sony Clie 4.0 converter
now attached to ttyUSB0 (or usb/tts/0 for devfs)
Oct 22 13:24:41 skohorod kernel: usbserial.c: Sony Clie 4.0 converter
now attached to ttyUSB1 (or usb/tts/1 for devfs)
Here is canceled the operation from the Palm since nothing happened.
Oct 22 13:25:44 skohorod kernel: usb-uhci.c: interrupt, status 3, frame#
2014
Oct 22 13:25:44 skohorod kernel: usb.c: USB disconnect on device 7
Oct 22 13:25:44 skohorod kernel: usbserial.c: Sony Clie 4.0 converter
now disconnected from ttyUSB0
Oct 22 13:25:44 skohorod kernel: usbserial.c: Sony Clie 4.0 converter
now disconnected from ttyUSB1
# sample.coldsyncrc
#
# $Id: sample.coldsync.rc,v 1.4 2000/09/22 15:09:21 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.
########################################
### 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/pilot";
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 "laurent" {
snum: "";
directory: "/home/usb/.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 .
########################################
### 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/usb/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
}