CedarBackup3.writers package — Cedar Backup v3 documentation

# CedarBackup3.writers package

Cedar Backup writers.

This package consolidates all of the modules that implenent “image writer” functionality, including utilities and specific writer implementations.

author: | Kenneth J. Pronovici <pronovic@ieee.org>

## Submodules

## CedarBackup3.writers.cdwriter module

Provides functionality related to CD writer devices.

### Module Attributes

`CedarBackup3.writers.cdwriter.` `MEDIA_CDRW_74`

  Constant representing 74-minute CD-RW media

`CedarBackup3.writers.cdwriter.` `MEDIA_CDR_74`

  Constant representing 74-minute CD-R media

`CedarBackup3.writers.cdwriter.` `MEDIA_CDRW_80`

  Constant representing 80-minute CD-RW media

`CedarBackup3.writers.cdwriter.` `MEDIA_CDR_80`

  Constant representing 80-minute CD-R media

author: | Kenneth J. Pronovici <pronovic@ieee.org>

class `CedarBackup3.writers.cdwriter.` `CdWriter`(device, scsiId=None, driveSpeed=None, mediaType=1, noEject=False, refreshMediaDelay=0, ejectDelay=0, unittest=False)

  Bases: `object`

  Class representing a device that knows how to write CD media.

  This is a class representing a device that knows how to write CD media. It provides common operations for the device, such as ejecting the media, writing an ISO image to the media, or checking for the current media capacity. It also provides a place to store device attributes, such as whether the device supports writing multisession discs, etc.

  This class is implemented in terms of the `eject` and `cdrecord` programs, both of which should be available on most UN*X platforms.

  Image Writer Interface

  The following methods make up the “image writer” interface shared with other kinds of writers (such as DVD writers):

      __init__
      initializeImage()
      addImageEntry()
      writeImage()
      setImageNewDisc()
      retrieveCapacity()
      getEstimatedImageSize()

  Only these methods will be used by other Cedar Backup functionality that expects a compatible image writer.

  The media attribute is also assumed to be available.

  Media Types

  This class knows how to write to two different kinds of media, represented by the following constants:

  > - `MEDIA_CDR_74`: 74-minute CD-R media (650 MB capacity)
  > - `MEDIA_CDRW_74`: 74-minute CD-RW media (650 MB capacity)
  > - `MEDIA_CDR_80`: 80-minute CD-R media (700 MB capacity)
  > - `MEDIA_CDRW_80`: 80-minute CD-RW media (700 MB capacity)

  Most hardware can read and write both 74-minute and 80-minute CD-R and CD-RW media. Some older drives may only be able to write CD-R media. The difference between the two is that CD-RW media can be rewritten (erased), while CD-R media cannot be.

  I do not support any other configurations for a couple of reasons. The first is that I’ve never tested any other kind of media. The second is that anything other than 74 or 80 minute is apparently non-standard.

  Device Attributes vs. Media Attributes

  A given writer instance has two different kinds of attributes associated with it, which I call device attributes and media attributes. Device attributes are things which can be determined without looking at the media, such as whether the drive supports writing multisession disks or has a tray. Media attributes are attributes which vary depending on the state of the media, such as the remaining capacity on a disc. In general, device attributes are available via instance variables and are constant over the life of an object, while media attributes can be retrieved through method calls.

  Talking to Hardware

  This class needs to talk to CD writer hardware in two different ways: through cdrecord to actually write to the media, and through the filesystem to do things like open and close the tray.

  Historically, CdWriter has interacted with cdrecord using the scsiId attribute, and with most other utilities using the device attribute. This changed somewhat in Cedar Backup 2.9.0.

  When Cedar Backup was first written, the only way to interact with cdrecord was by using a SCSI device id. IDE devices were mapped to pseudo-SCSI devices through the kernel. Later, extended SCSI “methods” arrived, and it became common to see `ATA:1,0,0` or `ATAPI:0,0,0` as a way to address IDE hardware. By late 2006, `ATA` and `ATAPI` had apparently been deprecated in favor of just addressing the IDE device directly by name, i.e. `/dev/cdrw`.

  Because of this latest development, it no longer makes sense to require a CdWriter to be created with a SCSI id – there might not be one. So, the passed-in SCSI id is now optional. Also, there is now a hardwareId attribute. This attribute is filled in with either the SCSI id (if provided) or the device (otherwise). The hardware id is the value that will be passed to cdrecord in the `dev=` argument.

  Testing

  It’s rather difficult to test this code in an automated fashion, even if you have access to a physical CD writer drive. It’s even more difficult to test it if you are running on some build daemon (think of a Debian autobuilder) which can’t be expected to have any hardware or any media that you could write to.

  Because of this, much of the implementation below is in terms of static methods that are supposed to take defined actions based on their arguments. Public methods are then implemented in terms of a series of calls to simplistic static methods. This way, we can test as much as possible of the functionality via testing the static methods, while hoping that if the static methods are called appropriately, things will work properly. It’s not perfect, but it’s much better than no testing at all.

  `__init__`(device, scsiId=None, driveSpeed=None, mediaType=1, noEject=False, refreshMediaDelay=0, ejectDelay=0, unittest=False)

    Initializes a CD writer object.

    The current user must have write access to the device at the time the object is instantiated, or an exception will be thrown. However, no media-related validation is done, and in fact there is no need for any media to be in the drive until one of the other media attribute-related methods is called.

    The various instance variables such as `deviceType`, `deviceVendor`, etc. might be `None`, if we’re unable to parse this specific information from the `cdrecord` output. This information is just for reference.

    The SCSI id is optional, but the device path is required. If the SCSI id is passed in, then the hardware id attribute will be taken from the SCSI id. Otherwise, the hardware id will be taken from the device.

    If cdrecord improperly detects whether your writer device has a tray and can be safely opened and closed, then pass in `noEject=False`. This will override the properties and the device will never be ejected.

    Note: The `unittest` parameter should never be set to `True` outside of Cedar Backup code. It is intended for use in unit testing Cedar Backup internals and has no other sensible purpose.

    Parameters: | device (Absolute path to a filesystem device, i.e. `/dev/cdrw`) – Filesystem device associated with this writer (If provided, SCSI id in the form ``[<method> (scsiId) – ]scsibus,target,lun``): SCSI id for the device (optional) driveSpeed (Use `2` for 2x device, etc. or `None` to use device default) – Speed at which the drive writes mediaType (One of the valid media type as discussed above) – Type of the media that is assumed to be in the drive noEject (Boolean true/false) – Overrides properties to indicate that the device does not support eject refreshMediaDelay (Number of seconds, an integer >= 0) – Refresh media delay to use, if any ejectDelay (Number of seconds, an integer >= 0) – Eject delay to use, if any unittest (Boolean true/false) – Turns off certain validations, for use in unit testing
    Raises: | `ValueError` – If the device is not valid for some reason `ValueError` – If the SCSI id is not in a valid form `ValueError` – If the drive speed is not an integer >= 1 `IOError` – If device properties could not be read for some reason

  `addImageEntry`(path, graftPoint)

    Adds a filepath entry to the writer’s associated ISO image.

    The contents of the filepath – but not the path itself – will be added to the image at the indicated graft point. If you don’t want to use a graft point, just pass `None`.

    Note: Before calling this method, you must call `initializeImage`.

    Parameters: | path (String representing a path on disk) – File or directory to be added to the image graftPoint (String representing a graft point path, as described above) – Graft point to be used when adding this entry
    Raises: | `ValueError` – If initializeImage() was not previously called

  `closeTray`()

    Closes the device’s tray.

    This only works if the device has a tray and supports ejecting its media. We have no way to know if the tray is currently open or closed, so we just send the appropriate command and hope for the best. If the device does not have a tray or does not support ejecting its media, then we do nothing.

    If the writer was constructed with `noEject=True`, then this is a no-op.

    Raises: | `IOError` – If there is an error talking to the device

  `device`

    Filesystem device name for this writer.

  `deviceBufferSize`

    Size of the device’s write buffer, in bytes.

  `deviceCanEject`

    Indicates whether the device supports ejecting its media.

  `deviceHasTray`

    Indicates whether the device has a media tray.

  `deviceId`

    Device identification, as returned from `cdrecord -prcap`.

  `deviceSupportsMulti`

    Indicates whether device supports multisession discs.

  `deviceType`

    Type of the device, as returned from `cdrecord -prcap`.

  `deviceVendor`

    Vendor of the device, as returned from `cdrecord -prcap`.

  `driveSpeed`

    Speed at which the drive writes.

  `ejectDelay`

    Eject delay, in seconds.

  `getEstimatedImageSize`()

    Gets the estimated size of the image associated with the writer. :returns: Estimated size of the image, in bytes

    Raises: | `IOError` – If there is a problem calling `mkisofs` `ValueError` – If initializeImage() was not previously called

  `hardwareId`

    Hardware id for this writer, either SCSI id or device path.

  `initializeImage`(newDisc, tmpdir, mediaLabel=None)

    Initializes the writer’s associated ISO image.

    This method initializes the `image` instance variable so that the caller can use the `addImageEntry` method. Once entries have been added, the `writeImage` method can be called with no arguments.

    Parameters: | newDisc (Boolean true/false) – Indicates whether the disc should be re-initialized tmpdir (String representing a directory path on disk) – Temporary directory to use if needed mediaLabel (String, no more than 25 characters long) – Media label to be applied to the image, if any

  `isRewritable`()

    Indicates whether the media is rewritable per configuration.

  `media`

    Definition of media that is expected to be in the device.

  `openTray`()

    Opens the device’s tray and leaves it open.

    This only works if the device has a tray and supports ejecting its media. We have no way to know if the tray is currently open or closed, so we just send the appropriate command and hope for the best. If the device does not have a tray or does not support ejecting its media, then we do nothing.

    If the writer was constructed with `noEject=True`, then this is a no-op.

    Starting with Debian wheezy on my backup hardware, I started seeing consistent problems with the eject command. I couldn’t tell whether these problems were due to the device management system or to the new kernel (3.2.0). Initially, I saw simple eject failures, possibly because I was opening and closing the tray too quickly. I worked around that behavior with the new ejectDelay flag.

    Later, I sometimes ran into issues after writing an image to a disc: eject would give errors like “unable to eject, last error: Inappropriate ioctl for device”. Various sources online (like Ubuntu bug #875543) suggested that the drive was being locked somehow, and that the workaround was to run ‘eject -i off’ to unlock it. Sure enough, that fixed the problem for me, so now it’s a normal error-handling strategy.

    Raises: | `IOError` – If there is an error talking to the device

  `refreshMedia`()

    Opens and then immediately closes the device’s tray, to refresh the device’s idea of the media.

    Sometimes, a device gets confused about the state of its media. Often, all it takes to solve the problem is to eject the media and then immediately reload it. (There are also configurable eject and refresh media delays which can be applied, for situations where this makes a difference.)

    This only works if the device has a tray and supports ejecting its media. We have no way to know if the tray is currently open or closed, so we just send the appropriate command and hope for the best. If the device does not have a tray or does not support ejecting its media, then we do nothing. The configured delays still apply, though.

    Raises: | `IOError` – If there is an error talking to the device

  `refreshMediaDelay`

    Refresh media delay, in seconds.

  `retrieveCapacity`(entireDisc=False, useMulti=True)

    Retrieves capacity for the current media in terms of a `MediaCapacity` object.

    If `entireDisc` is passed in as `True` the capacity will be for the entire disc, as if it were to be rewritten from scratch. If the drive does not support writing multisession discs or if `useMulti` is passed in as `False`, the capacity will also be as if the disc were to be rewritten from scratch, but the indicated boundaries value will be `None`. The same will happen if the disc cannot be read for some reason. Otherwise, the capacity (including the boundaries) will represent whatever space remains on the disc to be filled by future sessions.

    Parameters: | entireDisc (Boolean true/false) – Indicates whether to return capacity for entire disc useMulti (Boolean true/false) – Indicates whether a multisession disc should be assumed, if possible
    Returns: | `MediaCapacity` object describing the capacity of the media
    Raises: | `IOError` – If the media could not be read for some reason

  `scsiId`

    ]scsibus,target,lun``.

    Type: | SCSI id for the device, in the form ``[<method>

  `setImageNewDisc`(newDisc)

    Resets (overrides) the newDisc flag on the internal image. :param newDisc: New disc flag to set

    Raises: | `ValueError` – If initializeImage() was not previously called

  `unlockTray`()

    Unlocks the device’s tray. :raises: `IOError` – If there is an error talking to the device

  `writeImage`(imagePath=None, newDisc=False, writeMulti=True)

    Writes an ISO image to the media in the device.

    If `newDisc` is passed in as `True`, we assume that the entire disc will be overwritten, and the media will be blanked before writing it if possible (i.e. if the media is rewritable).

    If `writeMulti` is passed in as `True`, then a multisession disc will be written if possible (i.e. if the drive supports writing multisession discs).

    if `imagePath` is passed in as `None`, then the existing image configured with `initializeImage` will be used. Under these circumstances, the passed-in `newDisc` flag will be ignored.

    By default, we assume that the disc can be written multisession and that we should append to the current contents of the disc. In any case, the ISO image must be generated appropriately (i.e. must take into account any existing session boundaries, etc.)

    Parameters: | imagePath (String representing a path on disk) – Path to an ISO image on disk, or `None` to use writer’s image newDisc (Boolean true/false) – Indicates whether the entire disc will overwritten writeMulti (Boolean true/false) – Indicates whether a multisession disc should be written, if possible
    Raises: | `ValueError` – If the image path is not absolute `ValueError` – If some path cannot be encoded properly `IOError` – If the media could not be written to for some reason `ValueError` – If no image is passed in and initializeImage() was not previously called

class `CedarBackup3.writers.cdwriter.` `MediaCapacity`(bytesUsed, bytesAvailable, boundaries)

  Bases: `object`

  Class encapsulating information about CD media capacity.

  Space used includes the required media lead-in (unless the disk is unused). Space available attempts to provide a picture of how many bytes are available for data storage, including any required lead-in.

  The boundaries value is either `None` (if multisession discs are not supported or if the disc has no boundaries) or in exactly the form provided by `cdrecord -msinfo`. It can be passed as-is to the `IsoImage` class.

  `__init__`(bytesUsed, bytesAvailable, boundaries)

    Initializes a capacity object.

    Raises: | `IndexError` – If the boundaries tuple does not have enough elements `ValueError` – If the boundaries values are not integers `ValueError` – If the bytes used and available values are not floats

  `boundaries`

    Session disc boundaries, in terms of ISO sectors.

  `bytesAvailable`

    Space available on disc, in bytes.

  `bytesUsed`

    Space used on disc, in bytes.

  `totalCapacity`

    Total capacity of the disc, in bytes.

  `utilized`

    Percentage of the total capacity which is utilized.

class `CedarBackup3.writers.cdwriter.` `MediaDefinition`(mediaType)

  Bases: `object`

  Class encapsulating information about CD media definitions.

  The following media types are accepted:

  > - `MEDIA_CDR_74`: 74-minute CD-R media (650 MB capacity)
  > - `MEDIA_CDRW_74`: 74-minute CD-RW media (650 MB capacity)
  > - `MEDIA_CDR_80`: 80-minute CD-R media (700 MB capacity)
  > - `MEDIA_CDRW_80`: 80-minute CD-RW media (700 MB capacity)

  Note that all of the capacities associated with a media definition are in terms of ISO sectors (`util.ISO_SECTOR_SIZE)`.

  `__init__`(mediaType)

    Creates a media definition for the indicated media type. :param mediaType: Type of the media, as discussed above

    Raises: | `ValueError` – If the media type is unknown or unsupported

  `capacity`

    Total capacity of the media before any required lead-in.

  `initialLeadIn`

    Initial lead-in required for first image written to media.

  `leadIn`

    Lead-in required on successive images written to media.

  `mediaType`

    Configured media type.

  `rewritable`

    Boolean indicating whether the media is rewritable.

## CedarBackup3.writers.dvdwriter module

Provides functionality related to DVD writer devices.

### Module Attributes

`CedarBackup3.writers.dvdwriter.` `MEDIA_DVDPLUSR`

  Constant representing DVD+R media

`CedarBackup3.writers.dvdwriter.` `MEDIA_DVDPLUSRW`

  Constant representing DVD+RW media

author: | Kenneth J. Pronovici <pronovic@ieee.org>
author: | Dmitry Rutsky <rutsky@inbox.ru>

class `CedarBackup3.writers.dvdwriter.` `DvdWriter`(device, scsiId=None, driveSpeed=None, mediaType=2, noEject=False, refreshMediaDelay=0, ejectDelay=0, unittest=False)

  Bases: `object`

  Class representing a device that knows how to write some kinds of DVD media.

  Summary

  This is a class representing a device that knows how to write some kinds of DVD media. It provides common operations for the device, such as ejecting the media and writing data to the media.

  This class is implemented in terms of the `eject` and `growisofs` utilities, all of which should be available on most UN*X platforms.

  Image Writer Interface

  The following methods make up the “image writer” interface shared with other kinds of writers:

      __init__
      initializeImage()
      addImageEntry()
      writeImage()
      setImageNewDisc()
      retrieveCapacity()
      getEstimatedImageSize()

  Only these methods will be used by other Cedar Backup functionality that expects a compatible image writer.

  The media attribute is also assumed to be available.

  Unlike the `CdWriter`, the `DvdWriter` can only operate in terms of filesystem devices, not SCSI devices. So, although the constructor interface accepts a SCSI device parameter for the sake of compatibility, it’s not used.

  Media Types

  This class knows how to write to DVD+R and DVD+RW media, represented by the following constants:

  > - `MEDIA_DVDPLUSR`: DVD+R media (4.4 GB capacity)
  > - `MEDIA_DVDPLUSRW`: DVD+RW media (4.4 GB capacity)

  The difference is that DVD+RW media can be rewritten, while DVD+R media cannot be (although at present, `DvdWriter` does not really differentiate between rewritable and non-rewritable media).

  The capacities are 4.4 GB because Cedar Backup deals in “true” gigabytes of 1024*1024*1024 bytes per gigabyte.

  The underlying `growisofs` utility does support other kinds of media (including DVD-R, DVD-RW and BlueRay) which work somewhat differently than standard DVD+R and DVD+RW media. I don’t support these other kinds of media because I haven’t had any opportunity to work with them. The same goes for dual-layer media of any type.

  Device Attributes vs. Media Attributes

  As with the cdwriter functionality, a given dvdwriter instance has two different kinds of attributes associated with it. I call these device attributes and media attributes.

  Device attributes are things which can be determined without looking at the media. Media attributes are attributes which vary depending on the state of the media. In general, device attributes are available via instance variables and are constant over the life of an object, while media attributes can be retrieved through method calls.

  Compared to cdwriters, dvdwriters have very few attributes. This is due to differences between the way `growisofs` works relative to `cdrecord`.

  Media Capacity

  One major difference between the `cdrecord`/`mkisofs` utilities used by the cdwriter class and the `growisofs` utility used here is that the process of estimating remaining capacity and image size is more straightforward with `cdrecord`/`mkisofs` than with `growisofs`.

  In this class, remaining capacity is calculated by asking doing a dry run of `growisofs` and grabbing some information from the output of that command. Image size is estimated by asking the `IsoImage` class for an estimate and then adding on a “fudge factor” determined through experimentation.

  Testing

  It’s rather difficult to test this code in an automated fashion, even if you have access to a physical DVD writer drive. It’s even more difficult to test it if you are running on some build daemon (think of a Debian autobuilder) which can’t be expected to have any hardware or any media that you could write to.

  Because of this, some of the implementation below is in terms of static methods that are supposed to take defined actions based on their arguments. Public methods are then implemented in terms of a series of calls to simplistic static methods. This way, we can test as much as possible of the “difficult” functionality via testing the static methods, while hoping that if the static methods are called appropriately, things will work properly. It’s not perfect, but it’s much better than no testing at all.

  `__init__`(device, scsiId=None, driveSpeed=None, mediaType=2, noEject=False, refreshMediaDelay=0, ejectDelay=0, unittest=False)

    Initializes a DVD writer object.

    Since `growisofs` can only address devices using the device path (i.e. `/dev/dvd`), the hardware id will always be set based on the device. If passed in, it will be saved for reference purposes only.

    We have no way to query the device to ask whether it has a tray or can be safely opened and closed. So, the `noEject` flag is used to set these values. If `noEject=False`, then we assume a tray exists and open/close is safe. If `noEject=True`, then we assume that there is no tray and open/close is not safe.

    The SCSI id, if provided, is in the form `[<method>:]scsibus,target,lun`.

    Note: The `unittest` parameter should never be set to `True` outside of Cedar Backup code. It is intended for use in unit testing Cedar Backup internals and has no other sensible purpose.

    Parameters: | device – Absolute path to the writer filesystem device, like `/dev/dvd` scsiId – SCSI id for the device (optional, for reference only) driveSpeed – Speed at which the drive writes, like 2 for a 2x device, or None for device default mediaType – Type of the media that is assumed to be in the drive noEject (Boolean true/false) – Tells Cedar Backup that the device cannot safely be ejected refreshMediaDelay (Integer >= 0) – Refresh media delay to use, if any ejectDelay (Integer >= 0) – Eject delay to use, if any unittest (Boolean true/false) – Turns off certain validations, for use in unit testing
    Raises: | `ValueError` – If the device is not valid for some reason `ValueError` – If the SCSI id is not in a valid form `ValueError` – If the drive speed is not an integer >= 1

  `addImageEntry`(path, graftPoint)

    Adds a filepath entry to the writer’s associated ISO image.

    The contents of the filepath – but not the path itself – will be added to the image at the indicated graft point. If you don’t want to use a graft point, just pass `None`.

    Note: Before calling this method, you must call `initializeImage`.

    Parameters: | path (String representing a path on disk) – File or directory to be added to the image graftPoint (String representing a graft point path, as described above) – Graft point to be used when adding this entry
    Raises: | `ValueError` – If initializeImage() was not previously called `ValueError` – If the path is not a valid file or directory

  `closeTray`()

    Closes the device’s tray.

    This only works if the device has a tray and supports ejecting its media. We have no way to know if the tray is currently open or closed, so we just send the appropriate command and hope for the best. If the device does not have a tray or does not support ejecting its media, then we do nothing.

    Raises: | `IOError` – If there is an error talking to the device

  `device`

    Filesystem device name for this writer.

  `deviceCanEject`

    Indicates whether the device supports ejecting its media.

  `deviceHasTray`

    Indicates whether the device has a media tray.

  `driveSpeed`

    Speed at which the drive writes.

  `ejectDelay`

    Eject delay, in seconds.

  `getEstimatedImageSize`()

    Gets the estimated size of the image associated with the writer.

    This is an estimate and is conservative. The actual image could be as much as 450 blocks (sectors) smaller under some circmstances.

    Returns: | Estimated size of the image, in bytes
    Raises: | `IOError` – If there is a problem calling `mkisofs` `ValueError` – If initializeImage() was not previously called

  `hardwareId`

    Hardware id for this writer (always the device path).

  `initializeImage`(newDisc, tmpdir, mediaLabel=None)

    Initializes the writer’s associated ISO image.

    This method initializes the `image` instance variable so that the caller can use the `addImageEntry` method. Once entries have been added, the `writeImage` method can be called with no arguments.

    Parameters: | newDisc (Boolean true/false) – Indicates whether the disc should be re-initialized tmpdir (String representing a directory path on disk) – Temporary directory to use if needed mediaLabel (String, no more than 25 characters long) – Media label to be applied to the image, if any

  `isRewritable`()

    Indicates whether the media is rewritable per configuration.

  `media`

    Definition of media that is expected to be in the device.

  `openTray`()

    Opens the device’s tray and leaves it open.

    This only works if the device has a tray and supports ejecting its media. We have no way to know if the tray is currently open or closed, so we just send the appropriate command and hope for the best. If the device does not have a tray or does not support ejecting its media, then we do nothing.

    Starting with Debian wheezy on my backup hardware, I started seeing consistent problems with the eject command. I couldn’t tell whether these problems were due to the device management system or to the new kernel (3.2.0). Initially, I saw simple eject failures, possibly because I was opening and closing the tray too quickly. I worked around that behavior with the new ejectDelay flag.

    Later, I sometimes ran into issues after writing an image to a disc: eject would give errors like “unable to eject, last error: Inappropriate ioctl for device”. Various sources online (like Ubuntu bug #875543) suggested that the drive was being locked somehow, and that the workaround was to run ‘eject -i off’ to unlock it. Sure enough, that fixed the problem for me, so now it’s a normal error-handling strategy.

    Raises: | `IOError` – If there is an error talking to the device

  `refreshMedia`()

    Opens and then immediately closes the device’s tray, to refresh the device’s idea of the media.

    Sometimes, a device gets confused about the state of its media. Often, all it takes to solve the problem is to eject the media and then immediately reload it. (There are also configurable eject and refresh media delays which can be applied, for situations where this makes a difference.)

    This only works if the device has a tray and supports ejecting its media. We have no way to know if the tray is currently open or closed, so we just send the appropriate command and hope for the best. If the device does not have a tray or does not support ejecting its media, then we do nothing. The configured delays still apply, though.

    Raises: | `IOError` – If there is an error talking to the device

  `refreshMediaDelay`

    Refresh media delay, in seconds.

  `retrieveCapacity`(entireDisc=False)

    Retrieves capacity for the current media in terms of a `MediaCapacity` object.

    If `entireDisc` is passed in as `True`, the capacity will be for the entire disc, as if it were to be rewritten from scratch. The same will happen if the disc can’t be read for some reason. Otherwise, the capacity will be calculated by subtracting the sectors currently used on the disc, as reported by `growisofs` itself.

    Parameters: | entireDisc (Boolean true/false) – Indicates whether to return capacity for entire disc
    Returns: | `MediaCapacity` object describing the capacity of the media
    Raises: | `ValueError` – If there is a problem parsing the `growisofs` output `IOError` – If the media could not be read for some reason

  `scsiId`

    SCSI id for the device (saved for reference only).

  `setImageNewDisc`(newDisc)

    Resets (overrides) the newDisc flag on the internal image. :param newDisc: New disc flag to set

    Raises: | `ValueError` – If initializeImage() was not previously called

  `unlockTray`()

    Unlocks the device’s tray via ‘eject -i off’. :raises: `IOError` – If there is an error talking to the device

  `writeImage`(imagePath=None, newDisc=False, writeMulti=True)

    Writes an ISO image to the media in the device.

    If `newDisc` is passed in as `True`, we assume that the entire disc will be re-created from scratch. Note that unlike `CdWriter`, `DvdWriter` does not blank rewritable media before reusing it; however, `growisofs` is called such that the media will be re-initialized as needed.

    If `imagePath` is passed in as `None`, then the existing image configured with `initializeImage()` will be used. Under these circumstances, the passed-in `newDisc` flag will be ignored and the value passed in to `initializeImage()` will apply instead.

    The `writeMulti` argument is ignored. It exists for compatibility with the Cedar Backup image writer interface.

    Note: The image size indicated in the log (“Image size will be…”) is an estimate. The estimate is conservative and is probably larger than the actual space that `dvdwriter` will use.

    Parameters: | imagePath (String representing a path on disk) – Path to an ISO image on disk, or `None` to use writer’s image newDisc (Boolean true/false) – Indicates whether the disc should be re-initialized writeMulti (Boolean true/false) – Unused
    Raises: | `ValueError` – If the image path is not absolute `ValueError` – If some path cannot be encoded properly `IOError` – If the media could not be written to for some reason `ValueError` – If no image is passed in and initializeImage() was not previously called

class `CedarBackup3.writers.dvdwriter.` `MediaCapacity`(bytesUsed, bytesAvailable)

  Bases: `object`

  Class encapsulating information about DVD media capacity.

  Space used and space available do not include any information about media lead-in or other overhead.

  `__init__`(bytesUsed, bytesAvailable)

    Initializes a capacity object.

    Raises: | `ValueError` – If the bytes used and available values are not floats

  `bytesAvailable`

    Space available on disc, in bytes.

  `bytesUsed`

    Space used on disc, in bytes.

  `totalCapacity`

    Total capacity of the disc, in bytes.

  `utilized`

    Percentage of the total capacity which is utilized.

class `CedarBackup3.writers.dvdwriter.` `MediaDefinition`(mediaType)

  Bases: `object`

  Class encapsulating information about DVD media definitions.

  The following media types are accepted:

  > - `MEDIA_DVDPLUSR`: DVD+R media (4.4 GB capacity)
  > - `MEDIA_DVDPLUSRW`: DVD+RW media (4.4 GB capacity)

  Note that the capacity attribute returns capacity in terms of ISO sectors (`util.ISO_SECTOR_SIZE)`. This is for compatibility with the CD writer functionality.

  The capacities are 4.4 GB because Cedar Backup deals in “true” gigabytes of 1024*1024*1024 bytes per gigabyte.

  `__init__`(mediaType)

    Creates a media definition for the indicated media type. :param mediaType: Type of the media, as discussed above

    Raises: | `ValueError` – If the media type is unknown or unsupported

  `capacity`

    Total capacity of media in 2048-byte sectors.

  `mediaType`

    Configured media type.

  `rewritable`

    Boolean indicating whether the media is rewritable.

## CedarBackup3.writers.util module

Provides utilities related to image writers. :author: Kenneth J. Pronovici <pronovic@ieee.org>

class `CedarBackup3.writers.util.` `IsoImage`(device=None, boundaries=None, graftPoint=None)

  Bases: `object`

  Represents an ISO filesystem image.

  Summary

  This object represents an ISO 9660 filesystem image. It is implemented in terms of the `mkisofs` program, which has been ported to many operating systems and platforms. A “sensible subset” of the `mkisofs` functionality is made available through the public interface, allowing callers to set a variety of basic options such as publisher id, application id, etc. as well as specify exactly which files and directories they want included in their image.

  By default, the image is created using the Rock Ridge protocol (using the `-r` option to `mkisofs`) because Rock Ridge discs are generally more useful on UN*X filesystems than standard ISO 9660 images. However, callers can fall back to the default `mkisofs` functionality by setting the `useRockRidge` instance variable to `False`. Note, however, that this option is not well-tested.

  Where Files and Directories are Placed in the Image

  Although this class is implemented in terms of the `mkisofs` program, its standard “image contents” semantics are slightly different than the original `mkisofs` semantics. The difference is that files and directories are added to the image with some additional information about their source directory kept intact.

  As an example, suppose you add the file `/etc/profile` to your image and you do not configure a graft point. The file `/profile` will be created in the image. The behavior for directories is similar. For instance, suppose that you add `/etc/X11` to the image and do not configure a graft point. In this case, the directory `/X11` will be created in the image, even if the original `/etc/X11` directory is empty. I{This behavior differs from the standard `mkisofs` behavior!}

  If a graft point is configured, it will be used to modify the point at which a file or directory is added into an image. Using the examples from above, let’s assume you set a graft point of `base` when adding `/etc/profile` and `/etc/X11` to your image. In this case, the file `/base/profile` and the directory `/base/X11` would be added to the image.

  I feel that this behavior is more consistent than the original `mkisofs` behavior. However, to be fair, it is not quite as flexible, and some users might not like it. For this reason, the `contentsOnly` parameter to the `addEntry` method can be used to revert to the original behavior if desired.

  `__init__`(device=None, boundaries=None, graftPoint=None)

    Initializes an empty ISO image object.

    Only the most commonly-used configuration items can be set using this constructor. If you have a need to change the others, do so immediately after creating your object.

    The device and boundaries values are both required in order to write multisession discs. If either is missing or `None`, a multisession disc will not be written. The boundaries tuple is in terms of ISO sectors, as built by an image writer class and returned in a `writer.MediaCapacity` object.

    The boundaries parameter is a tuple of `(last_sess_start, next_sess_start)`, as returned from `cdrecord -msinfo`.

    Parameters: | device (Either be a filesystem path or a SCSI address) – Name of the device that the image will be written to boundaries – Session boundaries as required by `mkisofs`, or `None` graftPoint (String representing a graft point path (see `addEntry`)) – Default graft point for this page

  `addEntry`(path, graftPoint=None, override=False, contentsOnly=False)

    Adds an individual file or directory into the ISO image.

    The path must exist and must be a file or a directory. By default, the entry will be placed into the image at the root directory, but this behavior can be overridden using the `graftPoint` parameter or instance variable.

    You can use the `contentsOnly` behavior to revert to the “original” `mkisofs` behavior for adding directories, which is to add only the items within the directory, and not the directory itself.

    Note: Things get odd if you try to add a directory to an image that will be written to a multisession disc, and the same directory already exists in an earlier session on that disc. Not all of the data gets written. You really wouldn’t want to do this anyway, I guess.

    Note: An exception will be thrown if the path has already been added to the image, unless the `override` parameter is set to `True`.

    Note: The method `graftPoints` parameter overrides the object-wide instance variable. If neither the method parameter or object-wide value is set, the path will be written at the image root. The graft point behavior is determined by the value which is in effect I{at the time this method is called}, so you must set the object-wide value before calling this method for the first time, or your image may not be consistent.

    Note: You cannot use the local `graftPoint` parameter to “turn off” an object-wide instance variable by setting it to `None`. Python’s default argument functionality buys us a lot, but it can’t make this method psychic. :)

    Parameters: | path (String representing a path on disk) – File or directory to be added to the image graftPoint (String representing a graft point path, as described above) – Graft point to be used when adding this entry override (Boolean true/false) – Override an existing entry with the same path contentsOnly (Boolean true/false) – Add directory contents only (standard `mkisofs` behavior)
    Raises: | `ValueError` – If path is not a file or directory, or does not exist `ValueError` – If the path has already been added, and override is not set `ValueError` – If a path cannot be encoded properly

  `applicationId`

    Optionally specifies the ISO header application id value.

  `biblioFile`

    Optionally specifies the ISO bibliographic file name.

  `boundaries`

    Session boundaries as required by `mkisofs`.

  `device`

    Device that image will be written to (device path or SCSI id).

  `getEstimatedSize`()

    Returns the estimated size (in bytes) of the ISO image.

    This is implemented via the `-print-size` option to `mkisofs`, so it might take a bit of time to execute. However, the result is as accurate as we can get, since it takes into account all of the ISO overhead, the true cost of directories in the structure, etc, etc.

    Returns: | Estimated size of the image, in bytes
    Raises: | `IOError` – If there is a problem calling `mkisofs` `ValueError` – If there are no filesystem entries in the image

  `graftPoint`

    Default image-wide graft point (see `addEntry` for details).

  `preparerId`

    Optionally specifies the ISO header preparer id value.

  `publisherId`

    Optionally specifies the ISO header publisher id value.

  `useRockRidge`

    Indicates whether to use RockRidge (default is `True`).

  `volumeId`

    Optionally specifies the ISO header volume id value.

  `writeImage`(imagePath)

    Writes this image to disk using the image path.

    Parameters: | imagePath (String representing a path on disk) – Path to write image out as
    Raises: | `IOError` – If there is an error writing the image to disk `ValueError` – If there are no filesystem entries in the image `ValueError` – If a path cannot be encoded properly

`CedarBackup3.writers.util.` `readMediaLabel`(devicePath)

  Reads the media label (volume name) from the indicated device. The volume name is read using the `volname` command. :param devicePath: Device path to read from

  Returns: | Media label as a string, or None if there is no name or it could not be read

`CedarBackup3.writers.util.` `validateDevice`(device, unittest=False)

  Validates a configured device. The device must be an absolute path, must exist, and must be writable. The unittest flag turns off validation of the device on disk. :param device: Filesystem device path :param unittest: Indicates whether we’re unit testing

  Returns: | Device as a string, for instance `"/dev/cdrw"`
  Raises: | `ValueError` – If the device value is invalid `ValueError` – If some path cannot be encoded properly

`CedarBackup3.writers.util.` `validateDriveSpeed`(driveSpeed)

  Validates a drive speed value. Drive speed must be an integer which is >= 1. Note: For consistency, if `None` is passed in, `None` will be returned. :param driveSpeed: Speed at which the drive writes

  Returns: | Drive speed as an integer
  Raises: | `ValueError` – If the drive speed value is invalid

`CedarBackup3.writers.util.` `validateScsiId`(scsiId)

  Validates a SCSI id string. SCSI id must be a string in the form `[<method>:]scsibus,target,lun`. For Mac OS X (Darwin), we also accept the form `IO.*Services[/N]`. Note: For consistency, if `None` is passed in, `None` will be returned. :param scsiId: SCSI id for the device

  Returns: | 1,0,0”``
  Return type: | SCSI id as a string, for instance ``”ATA
  Raises: | `ValueError` – If the SCSI id string is invalid