Hi,
i stumbled over a prescription in xorriso's README:
"Currently it is fully supported [...]
on FreeBSD with ATAPI/CAM support enabled in the kernel, see atapicam(4)
"
What i read from
http://www.freebsd.org/cgi/man.cgi?query=atapicam&sektion=4
it could be that this is what's missing or not w
Hi,
> I got the same result and error message as I did when trying to dump the
> file system
The question towards FreeBSD developers is therefore:
Why does device "/dev/cd0" with this gesture
... in_fd = open (device,O_RDONLY)) ...
...
if (ioctl (in_fd,CAMGETPASSTHRU,&ccb)
Hi,
> >> :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device.
>
> Could someone else try to make a 'dump to DVD' backup [...]
> /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u
A test with less disk load would be to write e.g. 100 MB of zeros
to e.g.
Hi,
sorry for breaking this message thread. I was not subscribed
when i found it and so i have no Message Id to refer to.
I am only a casual user of CAM for DVD burning (once per release
cycle of libburn). But i can analyse some of the relation between
growisofs and the error messages.
> when a
Hi,
i am not sure whether this is the correct source code version
of makefs, but here i can see the reason for the bad Rock Ridge
TF entries
http://svnweb.freebsd.org/base/stable/8/usr.sbin/makefs/cd9660/iso9660_rrip.c?revision=224835&view=markup
Line 688 has:
p->attr.rr_entry.TF.h.l
Hi,
Warren Block wrote:
> sync will support hard links with -H
But how shall rsync know that the files in the ISO image stem from
hardlink siblings on the hard disk where the image was produced ?
I succeeded with this post-pr
Hi,
thanks for flying xorriso. :))
I am its developer and came to this thread by googling, not by
being subscribed here. Sorry for not having a message-id by which
i could attach this mail to the thread.
>>> libisofs: WARNING
