Hi, Hans wrote: > What I meant is more a desciption, > why xorriso-dd-target is better than dd or dcfldd.
xorriso-dd-target is effectively a frontend to lsblk, umount, and dd. Insofar i deem dd to be sufficient but not necessarily superior to other programs which can copy data to a USB stick or memory card. It's just that dd is nearly always available in a GNU/Linux system. Originally xorriso-dd-target was only intended as frontend to lsblk which can evaluate the suitability of target devices for any copy program. Without any arguments it will just list proposals of device names. $ xorriso-dd-target sdc $ But during conversations with Nio Wiklund alias sudodus, who provides a tool named "mkusb", it evolved to an optional helper for that program: https://help.ubuntu.com/community/mkusb#Additional_Feature:_mkusb-plug and to a quite standalone copier itself. The sequence of use cases in https://manpages.debian.org/bookworm/xorriso-dd-target/xorriso-dd-target.1.en.html reflects this evolution. While mkusb mostly addresses desktop GUI users, xorriso-dd-target restricts its dependencies to lsblk and vanilla shell equipment. > The last times I would say, every 2nd or 3rd run I got copy errors. Thisis > because the stick itself. I had several from the same manufacturer, all > failed> after a while. [...] All sticks were 16GB and newly bought. (say: > about 1 > year old) That sounds like really bad hardware. Mind to share manufacturer name and model name ? (I have a 2 GB Intenso model "USB", a 4 GB SanDisk Cruzer, a 8 GB Corsair Flash Voyager, and a 128 GB Intenso Ultra Line. They all are more than 5 years old. I use them rarely, except for the Corsair, which has a sturdy rubber coating and serves me as encrypted pocket backup medium.) > Hardware issue in the bootloader. You probably mean the firmware, not the bootloader, which would be data in the payload area of the stick. > Guess, the reformat is not intended for it. But this is crystal > clear: usb-sticks are made for Windows , for Windows and only for Windows. It's not _that_ bad. The difference is possibly that FAT filesystems have less metadata than ext filesystems. But in that context, nothing is as lightweight on firmware and hardware as a sequentially written filesystem image. One sweep, no random access, no repeated writing to a single logical block. Are you sure that possible write errors to FAT filesystems aren't just silently ignored by the stick's firmware ? If you otherwise use it with programs which checkread and complain, then the impression can appear that only those programs cause errors. You might get a more realistic impression if you manually checkread and compare the content of FAT with the data you have written. Have a nice day :) Thomas
