Provided by: hpoj_0.91-9_i386
hpoj reference: "ptal-photod"
ptal-photod devname [options...]
The "ptal-photod" daemon implements the "mtools" ""floppyd"" network
protocol. Its purpose is to let you use "mtools" as a portable method
for reading and writing files on photo cards inserted in hpoj-supported
multi-function peripherals. Such photo cards are normally formatted
with an MS-DOS FAT or VFAT file system.
· "devname" is the PTAL device name (required)
Recommended options: one (but usually not both) of the following:
· "-maxaltports n" -- tries up to n (for example, 26) successive
TCP/IP ports if the desired or default TCP/IP port address is
already in use, presumably by another "ptal-photod" or "floppyd"
· "-portoffset n" -- the desired TCP/IP port offset (default=0)
relative to the TCP/IP base port (see "-baseport" below)
Given the following lines in "/etc/mtools.conf" (for all users) or
"~/.mtoolsrc" (for specific users):
drive p: file=":0" remote drive q: file=":1" remote drive r: file=":2"
The "mtools" drive P: will be mapped to port 5703 on the local system,
drive Q: will be mapped to port 5704, and drive R: will be mapped to
· If you start "ptal-photod" as follows:
ptal-photod mlc:usb:PSC_900_Series -maxaltports 26 ptal-photod
mlc:usb:PHOTOSMART_100 -maxaltports 26
then "mlc:usb:PSC_900_Series" will be bound to port 5703 and
therefore drive P:, and "mlc:usb:PHOTOSMART_100" will be bound to
port 5704 and therefore drive Q:, because of the order in which the
two instances of "ptal-photod" are started. Drive R: will not have
anything bound to it.
· If you start "ptal-photod" as follows:
ptal-photod mlc:usb:PSC_900_Series -portoffset 1 ptal-photod
mlc:usb:PHOTOSMART_100 -portoffset 0 ptal-photod
mlc:usb:officejet_d_series -portoffset 1 # Will fail.
then "mlc:usb:PSC_900_Series" will be bound to port 5704 and
therefore drive Q:, and "mlc:usb:PHOTOSMART_100" will be bound to
port 5703 and therefore drive P:, because specific port offsets
relative to port 5703 were specified. However, the above
invocation for "mlc:usb:officejet_d_series" will fail, because the
""-portoffset 1"" switch conflicts with that of
"mlc:usb:PSC_900_Series". In order to safeguard against failures
due to inadvertently specifying the same "-portoffset" twice, you
can still also specify something like ""-maxaltports 26"", which
would have made "mlc:usb:officejet_d_series" roll over to port 5705
and therefore drive R:.
· "ptal-photod" logs startup and error messages to syslog
("/var/log/messages") in addition to logging to standard error.
· "ptal-photod" currently only supports photo cards which were
formatted with 512 bytes per sector.
· "ptal-photod" is somewhat slow, especially on older models, because
it currently reads/writes only one sector at a time when presented
with a multiple-sector request from "mtools".
· The "floppyd" protocol was originally designed for accessing local
floppy drives from a remote system you have logged into and set
your X-Windows display back to your local system. As a
consequence, "mtools" expects to find "X cookie" authentication
information for each X display number which corresponds to a remote
drive, even though "ptal-photod" doesn’t use this information. If
"mtools" gives some sort of "authentication failed" error message
with a given drive letter (for example, R:) and display number (for
example, "":2""), then run the command ""xauth add :2 . 00"",
substituting the correct display number in place of "":2"".
· If you use the "-bindto" or "-bindtoall" options to make the
device’s card-reader functionality available to other network
clients, then be careful to set up an appropriate firewall to
prevent untrusted clients (such as on the public Internet) from
accessing this service.
· If your device provides a standard USB mass-storage interface, you
may get better performance and usability if you use that access
method instead of "mtools" and "ptal-photod", because it allows you
to mount the card as a VFAT file system and use a wide variety of
Linux/Unix file-management tools.
· If you kill and restart "ptal-photod" (presumably via ""ptal-init
start"") too quickly, then sometimes "ptal-photod" is restarted
before the old instance’s TCP port is fully released, which may
cause the new instance to use a different TCP port, which will map
to a different drive letter, or to fail to start altogether. As a
workaround, ""ptal-init start"" delays before starting the first
instance of "ptal-photod", but if this isn’t enough and this
problem still occurs for you, then consider splitting the "restart"
operation into separate "stop" and "start" steps to give extra time
for the TCP port to get fully released.