[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dvd+rw-tools update [6.1, O_EXCL]



dvd+rw-tools 6.1 are available for download at usual location, http://fy.chalmers.se/~appro/linux/DVD+RW/. This is essentially minor bug-fix release, which most notably works around "unable to anonymously mmap" failure at startup and fixes typo in -speed interpretation code. Besides bug-fixes this version attempts to obtain exclusive lock on block device under Linux. This opens possibility for safe deployment of automounting/autoplaying facility under Linux 2.6. Keep in mind that it takes two to dance tango, automounters/autoplayers has to play along as well(*).

Given the responses I've got after 6.0 release message apparently reached rather far. This makes me hope that this message will reach out too. I'm truely sorry, but unfortunately I don't have time to answer individual questions already discussed on dvd+rw-tools pages, explicitly or implicitly, or on the list. Turn to your Linux vendor or a community forum for support! Personally I recommend <cdwrite@other.debian.org> list. I apologize in advance that discussions on this list tend to derail in rather "spectacular" ways, but it's in subscribers' power to create the atmosphere, not mine. On additinal note I'd recommend to keep in mind that when it comes to particular media brand support, it's your unit firmware that plays the key role, rather than recording application. In other words, do take time to actually test another media brand with your unit. A.

(*) Quoting source code:
        /*
         * Linux 2.6 kernel allows to claim O_EXCL on block device.
         * However! It does not really exclude the possibility for
         * another application to interfere with ongoing recording,
         * because kernel serializes *only* O_EXCL calls and lets
         * through those without. And the trouble naturally is that
         * there are automounting/autoplaying facilities, which
         * don't adhere to O_EXCL. Note that mount(2) system call
         * does acquire such exclusive lock at kernel level all by
         * itself, but most commonly it's user-land file system
         * detection subroutines, those determining 3rd argument
         * for mount(2) call, which turn to be the culprit. E.g.
         * among examined mount(8) and submountd(8) both were found
         * needing patching. Once mount(8) is patched, one can allow
         * autofs to handle DVD recorder [because automount deploys
         * mount(8)]. And once submountd(8) is patched it would be
         * possible to exempt subfs mount point from umount method
         * in transport.hxx. Keep in mind that this "list" is not
         * by any means complete...
         */



Reply to: