Imported Upstream version 3.3.3
[debian/amanda] / perl / Amanda / Device.pod
1 /*
2  * Copyright (c) 2009-2012 Zmanda, Inc.  All Rights Reserved.
3  *
4  * This program is free software; you can redistribute it and/or
5  * modify it under the terms of the GNU General Public License
6  * as published by the Free Software Foundation; either version 2
7  * of the License, or (at your option) any later version.
8  *
9  * This program is distributed in the hope that it will be useful, but
10  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
11  * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
12  * for more details.
13  *
14  * You should have received a copy of the GNU General Public License along
15  * with this program; if not, write to the Free Software Foundation, Inc.,
16  * 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
17  *
18  * Contact information: Zmanda Inc., 465 S. Mathilda Ave., Suite 300
19  * Sunnyvale, CA 94085, USA, or: http://www.zmanda.com
20  */
21
22 %perlcode %{
23
24 =head1 NAME
25
26 Amanda::Device - interact with Amanda data-storage devices
27
28 =head1 SYNOPSIS
29
30   use Amanda::Device qw( :constants );
31
32   my $dev = Amanda::Device->new($device_name);
33   if ($dev->read_label() == $DEVICE_STATUS_SUCCESS) {
34       print "Label on $device_name is '$dev->volume_label'\n";
35   }
36
37 =head1 DATA MODEL
38
39 A volume is a container for data which can be "loaded" into a particular
40 device. For tape devices, a volume is a tape, but most other devices do not
41 deal with such physical objects. Each volume has a volume header giving, among
42 other things, the label of the volume and the timestamp on which it was
43 written. The header may also indicate that the volume is not an Amanda volume.
44 Aside from the header, a volume contains a sequence of files, numbered starting
45 at 1. While writing, devices number files sequentially, but devices that
46 support partial volume recycling may have "holes" in the sequence of file
47 numbers where files have been deleted. The C<seek_file> method, below,
48 describes how the API represents this situation. Each file has a header, too,
49 which contains lots of information about the file. See L<Amanda::Header> for
50 the full list. After the header, a file is just a sequence of bytes.
51
52 Reads and writes to devices take place in blocks. Unlike a typical
53 operating-system file, in which any block boundaries are lost after the file is
54 written, devices must be read back with the block sizes that were used to read.
55 See C<amanda-devices(7)> for more in block sizes, and the read_block and
56 write_block sections, below, for more information.
57
58 =head1 USING THE DEVICE API
59
60 The Device API is object-oriented, so the first task in using the API is to
61 make a Device object:
62
63     $dev = Amanda::Device->new("tape:/dev/nst0");
64
65 This function takes a device name (possibly a device alias) and returns a
66 device object. This function always returns a Device, although it may be a Null
67 device with an error condition. Any C<new> call should be followed by a check
68 of the device's status:
69
70     $dev = Amanda::Device->new($device_name);
71     if ($dev->status() != $Amanda::Device::DEVICE_STATUS_SUCCESS) {
72       die "Could not open '$device_name': " . $dev->error();
73     }
74
75 This function does not access the underlying hardware or any other external
76 systems in any way: that doesn't happen until C<read_label> or C<start>.  An
77 Amanda configuration must be loaded when this function is called, as it
78 searches the configuation for device definitions.  The member variable
79 C<device_name> is set when this function has returned.
80
81 It is unusual for higher-level code to call C<< Amanda::Device->new >>.
82 Intead, use L<Amanda::Changer> to load a volume and reserve access to it; the
83 resulting reservation will contain an already-created Device object.
84
85 While Amanda proivdes multiple implementations of the Device class, they are
86 not distinguishable via the usual Perl methods (C<ref> or C<< $dev->isa >>).
87
88 Device users generally call device methods in the following order for reading:
89
90     read_label (optional)
91     start
92     seek_file (optional)
93     read_block (repeated)
94
95 or, when writing or appending:
96
97     read_label (optional)
98     start
99     start_file
100     write_block (repeated)
101     finish_file
102     finish
103
104 =head2 Alternate Constructor
105
106 To create a new RAIT device from a collection of device objects, call
107 C<< Amanda::Device->new_rait_from_children($child1, $child2, ..) >>.
108 If one of the child objects is C<undef>, the resulting RAIT device
109 will operate in degraded mode.
110
111 =head2 Error Handling
112
113 Device methods return a particular value to signal the presence of an error
114 condition. In many cases, this is simply false (exceptions are listed below).
115
116 When a device signals an error, C<< $dev->status >> and C<< $dev->error >>
117 contain details of what went wrong. Status is a bitfield where each bit that is
118 set indicates a possible problem. Unfortunately, some devices are unable to
119 distinguish states due to limitations of an external system. For example, the
120 tape device often cannot distinguish an empty drive
121 (C<$DEVICE_STATUS_VOLUME_MISSING>) from a hard device error
122 (C<$DEVICE_STATUS_DEVICE_ERROR>), leading to the status
123 C<$DEVICE_STATUS_VOLUME_MISSING>|C<$DEVICE_STATUS_DEVICE_ERROR>.  To be clear:
124 as few as one of the status bits may represent a actual problem.  If
125 C<$DEVICE_STATUS_VOLUME_UNLABELED> is set along with other bits, it is I<not>
126 safe to assume that an unlabeled volume is available.  However, if the bit is
127 not set, then it is safe to assume there is no unlabeled volume present.
128
129 =over 2
130
131 =item C<$DEVICE_STATUS_SUCCESS>
132
133 All OK (no bits set)
134
135 =item C<$DEVICE_STATUS_DEVICE_ERROR>
136
137 The device is in an unresolvable error state, and further retries are unlikely
138 to change the status
139
140 =item C<$DEVICE_STATUS_DEVICE_BUSY>
141
142 The device is in use, and should be retried later
143
144 =item C<$DEVICE_STATUS_VOLUME_MISSING>
145
146 The device itself is OK, but has no media loaded. This may change if media is
147 loaded by the user or a changer
148
149 =item C<$DEVICE_STATUS_VOLUME_UNLABELED>
150
151 The device is OK and media is laoded, but there is no Amanda header or an
152 invalid header on the media.
153
154 =item C<$DEVICE_STATUS_VOLUME_ERROR>
155
156 The device is OK, but there was an unresolvable error loading the header from
157 the media, so subsequent reads or writes will probably fail.
158
159 =back
160
161 At the risk of being repetitive, never test a device's status with C<==>,
162 unless it is to C<$DEVICE_STATUS_SUCCESS>. Furthermore, never try to parse the
163 device error messages -- they are only for user consumption, and may differ
164 from device to device.
165
166 In addition to the status bitfield, a Device also provides a
167 user-comprehensible error message, available from the methods C<error>
168 (returning the error message), C<status_error> (returning the string form of
169 the status), or C<status_or_error> (returning the error message if one is set,
170 otherwise the string form of the status). None of these functions will ever
171 return C<undef>.
172
173 =head2 Properties
174
175 Device properties provide a bidirectional means of communication between
176 devices and their users. A device provides values for some properties, which
177 other parts of Amanda can use to adjust their behavior to suit the device. For
178 example, Amanda will only attempt to append to a volume if the device's
179 properties indicate that it supports this activity. Some devices have
180 additional properties that can be set to control its activity. For example, the
181 S3 Device requires that the users' keys be given via properties.
182
183 See C<amanda-devices(7)> for more information on device properties and their
184 meanings.
185
186 The methods C<property_get> and C<property_set> are used to get and set
187 properties, respectively. If the indicated property simply does not exist,
188 these functions return an error indication (FALSE), but the device's status
189 remains C<$DEVICE_STATUS_SUCCESS>. If a more serious error occurs, then the
190 device's status is set appropriately.
191
192 Device properties are easy to handle, as the Perl-to-C glue takes care of all
193 necessary type conversions:
194
195     $success = $device->property_set("BLOCK_SIZE", $blocksize);
196     $blocksize = $device->property_get("BLOCK_SIZE");
197
198 If C<property_get> is called in an array context, it returns the property
199 value, its surety, and its source, in that order.  If there is an error
200 fetching the property, C<property_get> returns C<undef>.
201
202 The C<property_list()> method returns a list of all properties:
203
204   my @props = $device->property_list();
205
206 its return is an array of hashes:
207
208   ( { 'access' => $access_flags,
209       'name' => $property_name,
210       'description' => $property_description },
211     ...
212   )
213
214 =head3 Surety and Source
215
216 All properties have a source - where the value came from - and surety - a level
217 of confidence in the value. This can be used to decide which of two potentially
218 contradictory properties to believe. For example, the RAIT device examines the
219 source and surety of child devices' block sizes, prefering properties set by
220 the user (C<$PROPERTY_SOURCE_USER>) over others.
221
222 Set a property's source and surety with C<property_set_ex>:
223     $dev->property_set_ex("my_prop", 13, $PROPERTY_SURETY_BAD, $PROPERTY_SOURCE_DEFAULT);
224 The surety and source are returned after the property value in list context:
225     my ($val, $sur, $sou) = $dev->property_get("my_prop");
226
227 The available sureties are:
228
229   $PROPERTY_SURETY_GOOD
230   $PROPERTY_SURETY_BAD
231
232 and the sources are:
233
234   $PROPERTY_SOURCE_DEFAULT
235   $PROPERTY_SOURCE_DETECTED
236   $PROPERTY_SOURCE_USER
237
238 =head2 Concurrency
239
240 Some devices can perform more than one operation simultaneously, while others
241 are more limited. For example, a tape device is exclusive to a single process
242 while it is in use, while a VFS device can support concurrent reads and writes
243 on the same volume.
244
245 As of this writing, device locking is not correctly implemented in many
246 devices; consult the source code and check with the Amanda developers before
247 depending on concurrent operation of devices.
248
249 =head2 EOM and EOF
250
251 When writing to a volume, an EOM (end-of-media) condition occurs when no more
252 space is available on the volume.  Some devices (currently only those
253 supporting DirectTCP) distinguish a logical EOM (LEOM) from a physical EOM
254 (PEOM).  The logical EOM comes some distance before the physical EOM, with
255 enough space left to finish a data block and write any additional bookkeeping
256 data before PEOM.
257
258 In such devices, the C<is_eom> attribute is set once LEOM is detected.  Such
259 detection can happen in any method that writes to the volume, including
260 C<start>, C<start_file>, C<finish_file>, and C<finish>.  API users that
261 understand LEOM should take this as a signal to complete writing to the device
262 and move on before hitting PEOM.
263
264 Devices which do not support LEOM simply return a VOLUME_ERROR when the volume
265 is full.  If this occurs during a C<write_block> operation, then the volume may
266 or may not contain the block - the situation is indeterminate.
267
268 Devices indicate their support for LEOM with the LEOM property.
269
270 =head2 Device Resources
271
272 Some device types have a "locking" mechanism that prevents other parts of the
273 system from accessing the underlying resource while an operation is in
274 progress.  For example, a typical UNIX tape driver cannot be opened by two
275 processes at once.
276
277 Amanda Devices will lock the underlying resource when C<start> or C<read_label>
278 is called, and unlock the resource either when the Device object is
279 garbage-collected or in the C<finish> method.  Thus in a calling sequence such as
280
281     read_label
282     start
283     seek_file
284     ...
285     finish
286
287 the underlying resource remains locked for the entire sequence, even between
288 read_label and finish.
289
290 It is unwise to rely on Perl's garbage-collection to automatically release
291 resources.  Instead, always explicitly release resources with a C<finish> call.
292 The Changer API is careful to do this in its C<release> method.
293
294 =head2 Member Variables
295
296 All member variables are implemented using accessor methods, rather than the
297 more common hashref technique.  Use
298
299   print $dev->device_name, "\n";
300
301 instead of
302
303   print $dev->{'device_name'}, "\n";
304
305 The member variables are:
306
307 =over 4
308
309 =item C<file>
310
311 the current file number, if any
312
313 =item C<block>
314
315 the current block number, if any
316
317 =item C<in_file>
318
319 true if the device is in the middle of reading or writing a file
320
321 =item C<device_name>
322
323 the name with which the device was constructed; note that this is not set until after open_device is finished -- it is an error to access this variable in an open_device implementation
324
325 =item C<access_mode>
326
327 the current access mode (C<$ACCESS_NULL>, or that supplied to start)
328
329 =item C<is_eof>
330
331 true if an EOF occurred while reading; also used by C<write_from_connection>
332
333 =item C<is_eom>
334
335 true if a write operation reached the end of the volume (end-of-medium)
336
337 =item C<volume_label>
338
339 the label of the current volume, set by start and read_label
340
341 =item C<volume_time>
342
343 the timestamp of the current volume, set by start and read_label
344
345 =item C<volume_header>
346
347 the header of the current volume, set by read_label
348
349 =item C<status>
350
351 the device's error status (bit flags) as an integer
352
353 =item C<status_error>
354
355 the device's error status (bit flags) as a string
356
357 =item C<error>
358
359 the device's error message
360
361 =item C<error_or_status>
362
363 the device's error message, if set, otherwise the same as C<status_error> --
364 use this to display error messages from devices
365
366 =item C<block_size>
367
368 the device's currently configured block size. This is also available via the
369 BLOCK_SIZE property. Writers should use block_size-byte blocks, and readers
370 should initially use block_size, and expand buffers as directed by
371 C<read_block>.
372
373 =item C<min_block_size>
374
375 minimum allowed block size for this device
376
377 =item C<max_block_size>
378
379 maximum allowed block size for this device
380
381 =back
382
383 =head2 Object Methods
384
385 =head3 configure($use_global_config)
386
387     $dev->configure(1);
388
389 Once you have a new device, you should configure it. This sets properties on
390 the device based on the user's configuation. If C<$use_global_config> is true,
391 then any global C<device_property> parameters are processed, along with
392 tapetype and other relevant parameters. Otherwise, only parameters from the
393 device definition (if the device was opened via an alias) are processed.
394
395 This method is I<deprecated>.  All access to Devices should be via the Changer
396 API (see L<Amanda::Changer>), which implements its own, more advanced method of
397 configuring devices.  The C<configure> method may be removed in a future
398 release.
399
400 =head3 read_label
401
402     $status = $dev->read_label();
403
404 This function reads the tape header of the current volume, returning the
405 Device's status (see "Error Handling", above). Since this is often the first
406 function to accses the underlying hardware, its error status is the one most
407 often reported to the user. In fact, C<amdevcheck(8)> is little more than a
408 wrapper around read_label.
409
410 The method sets the following member variables:
411
412 =over 4
413
414 =item C<volume_header>
415
416 if any header data was read from the volume, it is represented here. The
417 header's type may be F_WEIRD if the header was not recognized by Amanda.
418
419 =item C<volume_label>
420
421 if read_label read the header successfully, then volume_label contains the
422 label
423
424 =item C<volume_time>
425
426 smililarly, if read_label read the header successfully, then volume_time
427 contains the timestamp from the header
428
429 =back
430
431 =head3 start
432
433     $succss = $dev->start($ACCESS_WRITE, $label, $timestamp);
434
435 Start starts the device and prepares it for the use described by its second
436 parameter. This function can be called regardless of whether C<read_label> has
437 already been called.
438
439 If the access mode is C<$ACCESS_WRITE>, then the label and timestamp must be
440 supplied (although leaving the timestamp undef will use the current time), and
441 they will be used to write a new volume header. Otherwise, these parameters
442 should be undef.
443
444 On completion, start leaves the device's C<access_mode>, C<volume_label> and
445 C<volume_time> member variables set, by reading the tape header if necessary.
446 Note that in mode C<$ACCESS_APPEND>, the C<file> member variable is not set
447 until after C<start_file> has been called.
448
449 =head3 start_file
450
451  $success = $dev->start_file($header);
452
453 This method prepares the device to write data into a file, beginning by writing
454 the supplied header to the volume. On successful completion, the device's
455 C<file> is set to the current file number, C<block> is zero, and C<in_file> is
456 true.  If the volume is out of space, the C<is_eom> member is set to true and
457 the method returns false with status C<DEVICE_STATUS_VOLUME_ERROR>.
458
459 =head3 write_block
460
461  # (not available from Perl)
462  success = device_write_block(dev, blocksize, buf);
463
464 This method writes a single block of data to the volume.  It is only available
465 from C -- Perl code should not be handling raw data, as it is far too slow.
466 Use the transfer architecture (L<Amanda::Xfer>) for that purpose.
467
468 The C<blocksize> must be the device's block size, unless
469 this is a short write.  A short write must be the last block
470 of a file. Some devices will zero-pad a short write to a full
471 blocksize. This method returns false on error.  If the volume is
472 out of space, C<is_eom> is set and the method returns false with
473 status C<DEVICE_STATUS_VOLUME_ERROR>.  Note that not all devices can
474 differentiate an EOM condition from other errors; these devices will
475 set C<is_eom> whenever the situation is ambiguous.
476
477 This function ensures that C<block> is correct on exit. Even in an
478 error condition, it does not finish the current file for the caller.
479
480 =head3 finish_file
481
482  $success = $dev->finish_file();
483
484 Once an entire file has been written, finish_file performs any
485 cleanup required on the volume, such as writing filemarks. On exit,
486 C<in_file> is false.  If the device runs out of space while finishing
487 (e.g., the filemark does not fit), then this method returns false
488 with status C<DEVICE_STATUS_VOLUME_ERROR> and C<is_eom> is set.
489
490 This function should not be used while reading -- instead, just seek
491 to the next file.
492
493 =head3 seek_file
494
495  $header = $dev->seek_file($fileno);
496
497 In C<$ACCESS_READ>, C<seek_file> sets up the device to read from file
498 C<$fileno>. This function is not available in C<$ACCESS_WRITE> and
499 C<$ACCESS_APPEND>. It returns the header from the requested file on success, or
500 undef on error.
501
502 If the requested file doesn't exist, as might happen when a volume has had
503 files recycled, then C<seek_file> will seek to the next file that does exist. The
504 file this function selected is indicated by the C<file> member variable on exit.
505 If the requested file number is exactly one more than the last valid file, this
506 function returns a C<$F_TAPEEND> header.
507
508 As an example, on a volume with only files 1 and 3:
509
510  $dev->seek_file(1) returns header for file 1, $dev->file == 1
511  $dev->seek_file(2) returns header for file 3, $dev->file == 3
512  $dev->seek_file(3) returns header for file 3, $dev->file == 3
513  $dev->seek_file(4) returns a tapend header, $dev->file == 4
514  $dev->seek_file(5) returns NULL/undef
515
516 On exit, C<is_eof> is false, C<in_file> is true unless no file was found (tapeend or NULL), C<file> is the discovered file, and C<block> is zero.
517
518 =head3 seek_block
519
520  $success = $dev->seek_block($block);
521
522 After seeking to a file, the caller can optionally seek to a particular block
523 in the file. This function will set C<block> appropriately. Note that it may
524 not be possible to detect EOF, so this function may fail to set C<is_eof> even
525 though a subsequent C<read_block> will return no data.
526
527 =head3 read_block
528
529  # (not available from Perl)
530  bytes_read = device_read_block(dev, buffer, *blocksize);
531
532 This method is the complement of C<write_block>, and reads the next block from
533 the device, or returns -1 on error. Pass a buffer and its size. If the buffer
534 is not big enough, no read is performed, the parameter C<blocksize> is set to
535 the required blocksize, and the method returns 0. As a special case, passing a
536 C<NULL> buffer and C<*blocksize == 0> is treated as a request for the required block
537 size. It is not an error to pass a buffer that is too large (and, in fact, this
538 is precisely the effect of setting the C<read_block_size> configuration
539 parameter).
540
541 On EOF, this method returns -1, but sets C<is_eof> and leaves the device's
542 status set to C<$DEVICE_STATUS_SUCCESS>. Some devices may be able to detect EOF
543 while reading the last block, and will set C<is_eof> at that time. Others must
544 wait for the next read to fail. It is never an error to call C<read_block>
545 after an EOF, so there is no need to check C<is_eof> except when C<read_block>
546 returns -1.
547
548 =head3 finish
549
550  $success = $dev->finish();
551
552 This undoes the effects of start, returning the device to a neutral state
553 (C<$ACCESS_NULL>).  It will also release any resources acquired by
554 C<read_label>, even if C<start> was not called.  After C<finish>, it is not an
555 error to call C<start> again, even with a different mode.
556
557 =head3 recycle_file
558
559  $success = $dev->recycle_file(fileno);
560
561 On devices that support it, this removes the indicated file from the volume,
562 presumably freeing its space to be used for other files. File numbers of
563 existing files will not change, so this operation may leave "holes" in the
564 sequence of file numbers. See C<seek_file> to see how this is handled.
565
566 This method cannot be called while in a file, nor while in C<$ACCESS_READ>
567 mode.
568
569 =head3 erase
570
571  $success = $dev->erase(fileno);
572
573 On devices that support it, this erases all data from the volume, presumably
574 freeing the space.  This method must be called before start and after finish --
575 that is, while the device is in a neutral state (C<$ACCESS_NULL>). You can
576 detect whether or not this operation is supported using the C<full_deletion>
577 property.
578
579 =head3 eject
580
581  $success = $dev->eject();
582
583 On devices that support it, this eject the volume.  This method can be called
584 before start and after finish.
585
586 =head3 directtcp_supported
587
588   $supp = $dev->directtcp_supported();
589
590 This method returns TRUE if the DirectTCP-related methods (C<listen>,
591 C<accept>, C<write_from_connection>, and C<read_to_connection>) are implemented
592 by this device.
593
594 =head3 listen
595
596   $addrs = $dev->listen($for_writing);
597
598 The C<listen> method starts the device listening for an incoming DirectTCP
599 connection.  The method returns a set of IP:PORT pairs to which a TCP
600 connection can be made.  The boolean C<for_writing> is TRUE if
601 this connection will be used to write to the device.
602
603 This method can be called at any time, but between the time C<listen> is called
604 and when C<accept> returns, no other methods of the device should be called.
605
606 The return value might look like:
607
608   $addrs = [ [ "127.0.0.1", 9382 ] ]
609
610 In C, the memory for these addresses remains the responsibility of the device,
611 and will remain unchanged until C<accept> returns.
612
613 =head3 accept
614
615   $conn = $dev->accept();
616
617 This method accepts a connection to one of the addresses returned by C<listen>,
618 returning an established DirectTCPConnection object (see below).  It returns
619 C<undef> on failure.  Note that this method may block indefinitely if no
620 connection ever occurs.  The C implementation returns an already-referenced
621 connection object, so the caller should call C<g_object_unref> when the
622 connection is no longer needed.
623
624 =head3 connect
625
626   $conn = $dev->connect($for_writing, $addrs);
627
628 This method initiates a connection to one of the addresses in C<$addrs>,
629 returning an established DirectTCPConnection object (see below).  The
630 C<$for_writing> parameter is TRUE if the connection will be used to write to
631 the device.  It returns C<undef> on failure.  Note that this method may block
632 indefinitely if no connection ever occurs.  The C implementation returns an
633 already-referenced connection object, so the caller should call
634 C<g_object_unref> when the connection is no longer needed.
635
636 =head3 use_connection
637
638   my $ok = $dev->use_connection($conn);
639
640 Call this method to use a DirectTCPConnection object created with another
641 device.  The method must be called before the device is started (so
642 C<access_mode> is C<$ACCESS_NULL>), as some devices cannot support switching
643 connections without rewinding.  Any subsequent C<read_to_connection> or
644 C<write_from_connection> calls will use this connection.
645
646 =head3 write_from_connection
647
648   ($ok, $actual_size) = $dev->write_from_connection($size);
649
650 This method reads data from the DirectTCPConnection specified with
651 C<use_connection> or returned from C<accept> or C<connect> and writes it to the
652 volume.   It writes at most C<$size> bytes, and returns the number of bytes
653 written in C<$actual_size>.  If C<$size> is zero, it will write until EOF, EOM,
654 or a device error.  On error, C<$ok> is false.
655
656 When an EOF is received over the connection, signalling the end of the data
657 stream, then this method returns without error (C<$ok> is true), with
658 C<$actual_size> indicating the number of bytes written to the device (which may
659 be zero).  In this case, the C<is_eof> attribute is true on return.
660
661 Similarly, when the device encounters logical EOM in this method, it returns
662 the total bytes transferred in C<$actual_size>, with C<$ok> true, and the
663 C<is_eom> attribute true.  No data is lost.  If writes continue until physical
664 EOM, data may be lost.
665
666 =head3 read_to_connection
667
668   ($ok, $actual_size) = $dev->read_to_connection($size);
669
670 This method is similar to C<write_from_connection> but the data flows in the
671 opposite direction.  It reads at most C<$size> bytes, and returns the total
672 number of bytes read in C<$actual_size>.
673
674 When the method encounters an EOF, it stops early and returns successfully with
675 the number of bytes actually read (which may be zero).
676
677 =head3 property_get
678
679 Get a property value, where the property is specified by name.  See "Properties", above.
680
681 =head3 property_set
682
683 Set a simple property value.  See "Properties", above.
684
685 =head3 property_set_ex
686
687 Set a property value with surety and source.  See "Properties", above.
688
689 =head2 CONSTANTS
690
691 This module defines a large number of constant scalars.  These constants are
692 available from the package namespace (e.g., C<$Amanda::Device::ACCESS_WRITE>),
693 or imported with the C<:constant> import tag.
694
695 =head2 DirectTCPConnection objects
696
697 The C<accept> and C<connect> methods return an object to represent the ongoing
698 DirectTCP connection.  This object is mostly useful as a "token" to be passed
699 to C<write_from_connection> and C<read_to_connection>.  In particular, a
700 connection created by one device can be used with another device; this is how
701 DirectTCP dumps are spanned over multiple volumes.
702
703 The class does have one critical method, though:
704
705   $conn->close();
706
707 This method closes the connection, releasing all resources allocated to it.  It
708 can be called at any time, whether the remote side has closed the connection
709 already or not.
710
711 =cut
712
713 %}