tags 805495 patch found 805495 3:4.8.15-1 thanks
On Thu 19 Nov 2015 at 20:30:57 +0100, Thomas Schmitt wrote: > Hi, > > > With isoinfo the time to copy > > the pool directory from debian-8.2.0-i386-netinst.iso is about 26s. > > [...] > > xorriso -osirrox on -indev debian-8.2.0-i386-netinst.iso -extract pool > > DESTINATION > > takes a mere 2s. > > This is a situation where ISO tree loading of xorriso is superior > to repeated disk i/o of isoinfo. > > > > Using xorriso [under mc] the time taken is about 40s. > > Possibly mc is running one xorriso process per data file, > rather than letting it extract the whole directory tree. > > > > I could understand isoinfo being slowish because I think it copies files > > one by one, but surely xorriso is capable of better integration into mc? > > The ideal candidate would be > xorriso -dialog on > attached via two pipes. > There are examples in > http://libburnia-project.org/browser/libisoburn/trunk/frontend > for C (frontend_pipes_xorriso.c ), > for bash (sh_on_named_pipes.sh), > and for Tcl/Tk (xorriso-tcltk). > > > > /usr/lib/mc/extfs.d/iso9660 > > This here seems outdated: > > http://repo.or.cz/midnight-commander.git/tree/refs/heads/master:/src/vfs/extfs/helpers/iso9660.in > More modern: > https://www.midnight-commander.org/browser/src/vfs/extfs/helpers/iso9660.in > > It seems that the abstraction of filesystem operations > applies to single file objects. It is not obvious whether > mc will apply the methods to whole directory trees or > rather will walk the trees and process single data files. > > Quite disturbing are the methods xorriso_copyin, xorriso_mkdir, > xorriso_rmdir, and xorriso_rm. (Why isn't there xorriso_mv ?) > They add a whole new session to the ISO in order to add their > file object to the ISO. Each time, the whole ISO filesystem tree > will be written. (Not to speak of the limitations of optical > media in respect to number of sessions.) > > --------------------------------------------------------- > > Roadmap proposal for performance improvement: [....] xorriso was introduced into mc as a result of https://www.midnight-commander.org/ticket/3027 The request was for *changing content* of ISO-images. However, its role was extended to give it priority over isoinfo for listing and copying out. This happens unknown to the user and, if the suggested genisoimage is installed, subverts the user's choice of software. Because of the stated advantage of xorriso over isoinf this might be overlooked if did not produce a degraded experience for the user. A return to the previous list and copyout behaviour could be done by patching /usr/lib/mc/extfs.d/iso9660: case "$cmd" in list) test_iso "$@"; mcisofs_list "$@"; || { xorriso_list "$@" } exit 0 ;; copyout) test_iso "$@"; mcisofs_copyout "$@"; || { xorriso_copyout "$@" exit 0 ;; esac This would still leave open the question of optimising the use of xorriso within mc, which is likely an upstream issue, and might need a Suggests: xorriso added to the package data. Regards, Brian.
