Home | Trees | Indices | Help |
|
---|
|
object --+ | DvdWriter
Class representing a device that knows how to write some kinds of DVD media.
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.
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.
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.
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
.
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.
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.
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
Inherited from |
|
|||
|
|||
|
|||
|
|||
|
|
|||
device Filesystem device name for this writer. |
|||
scsiId SCSI id for the device (saved for reference only). |
|||
hardwareId Hardware id for this writer (always the device path). |
|||
driveSpeed Speed at which the drive writes. |
|||
media Definition of media that is expected to be in the device. |
|||
deviceHasTray Indicates whether the device has a media tray. |
|||
deviceCanEject Indicates whether the device supports ejecting its media. |
|||
refreshMediaDelay Refresh media delay, in seconds. |
|||
ejectDelay Eject delay, in seconds. |
|||
Inherited from |
|
Initializes a DVD writer object. Since We have no way to query the device to ask whether it has a tray or can
be safely opened and closed. So, the
Note:
The |
Retrieves capacity for the current media in terms of a
If
|
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.
|
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.
|
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.
|
Initializes the writer's associated ISO image. This method initializes the
|
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
Note: Before calling this method, you must call initializeImage. |
Writes an ISO image to the media in the device. If If The
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 |
Resets (overrides) the newDisc flag on the internal image.
|
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.
|
Writes an image to disc using either an entries list or an ISO image on disk. Callers are assumed to have done validation on paths, etc. before calling this method.
|
Gets the estimated size of a set of image entries. This is implemented in terms of the
|
Search for an "overburn" error message in
The The error message looks like this: :-( /dev/cdrom: 894048 blocks are free, 2033746 to be written! This method looks for the overburn error message anywhere in the
output. If a matching error message is found, an
|
Builds a list of arguments to be passed to a The arguments will either cause If a new image is created, it will always be created with Rock Ridge
extensions (-r). A volume name will be applied (-V) if
Notes:
|
Unlocks the device's tray via 'eject -i off'.
|
Retrieves the number of sectors used on the current media. This is a little ugly. We need to call growisofs in "dry-run" mode and parse some information from its output. However, to do that, we need to create a dummy file that we can pass to the command -- and we have to make sure to remove it later. Once growisofs has been run, then we call
|
Parse sectors used information out of The first line of a growisofs run looks something like this: Executing 'mkisofs -C 973744,1401056 -M /dev/fd/3 -r -graft-points music4/=music | builtin_dd of=/dev/cdrom obs=32k seek=87566' Dmitry has determined that the seek value in this line gives us information about how much data has previously been written to the media. That value multiplied by 16 yields the number of sectors used. If the seek line cannot be found in the output, then sectors used of zero is assumed.
|
|
deviceFilesystem device name for this writer.
|
scsiIdSCSI id for the device (saved for reference only).
|
hardwareIdHardware id for this writer (always the device path).
|
driveSpeedSpeed at which the drive writes.
|
mediaDefinition of media that is expected to be in the device.
|
deviceHasTrayIndicates whether the device has a media tray.
|
deviceCanEjectIndicates whether the device supports ejecting its media.
|
refreshMediaDelayRefresh media delay, in seconds.
|
ejectDelayEject delay, in seconds.
|
Home | Trees | Indices | Help |
|
---|
Generated by Epydoc 3.0.1 on Thu May 9 21:18:27 2013 | http://epydoc.sourceforge.net |