Hi, JBThiel wrote: > 1) '-add ./ -- ' fails as below.
Looks like an old bug. I will investigate further. > 2) I recently realized that -check_media does not check the md5 unless > '-md5 on' or -for_backup. This is a featurei explained in the man page. The MD5 verification can be switched on or off between other commands at discretion of the user. Even without checksum verification, a test of error-less readabilty can be performed. > 3) I was reviewing the zisofs compression feature, excellent but it has > limit 4g file size. Inventor is H.Peter Anvin. I only joined in later. > It would be > nice to get transparent compression on bigger files, so they are usable in > place directly from the optical. Any prospects for that? The definition of an extended version would not be overly hard. But the charm of zisofs is that it is implemented as read facility in the Linux kernel: fs/isofs/zisofs.h, fs/isofs/inode.c, fs/isofs/rock.c, control macro CONFIG_ZISOFS. Without such a support in the kernel, you can as well simply use .gz by the built-in filter "--gzip", or others by external filters. The inconvenience comes with the need for an explicit decompression. If you see an opportunity to get a new decompression method into the kernel as alternative to zisofs, then i'd be interested in such a project. (But i have linux-scsi bug fixes dangling already, for which nobody cares.) > 4) I have thought that Xorriso could be listed under Archivers, This is one of its roles. Main role for me personally. Wikipedia expects third-party writers to describe things. People, who are involved in the described thing, are supposed to stay off. Well, sometimes i correct factual mistakes. > 5) An extremely useful feature I have thought would be a perfect extension > for Xorriso, would be adding ECC / Parity Checksum data, We would need to explore the technical opportunities: - A library to read and write and at least one free tool to read the format. - A plan where and how to apply the format so that the ISO 9660 filesystem still can be read by normal means. Else we can as well postprocess the ISOs and leave everything to the external tools. Without knowing more about the library, there is few base for a plan. So this idea still needs much more beef on its bones. Please add some, in the light of https://en.wikipedia.org/wiki/ISO_9660 which gives the overall structure of the filesystem. Especially important will be a strategy how a reader first repairs the superblock, then the directory tree, and finally file content and attribute data. As stated above, an enhanced ISO must still be readable by unaware tools and operating systems. Read performance should not suffer much impact. So interlacing payload and redundancy data is probably not feasible. But we could store extra data in larger areas besides the file data areas (interlaced with multi-MB granularity, maybe). The connection between files and extra data could be implemented like with files and MD5: https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/checksums.txt Have a nice day :) Thomas
