Hi, i quoted man bzip2: > > As with compression, supplying no filenames causes decompression from > > standard input to standard output."
GiaThnYgeia wrote: > ...aka screen dump? If the standard output of bzip2 is not connected to the standard input of another process or redirected to a file, then i'd call that a terminal flood. Ugly text salad which may even change display settings of your terminal window. Standard input, standard output, and standard error output are three i/o channels which every process on a Unix-like system has. Connecting them to other i/o channels or redirecting them to files is a fundamental gesture of shell programming. (Yes, the shell is a programming language, although we often only execute single command lines.) > > In what state is "imagefile" now ? Compressed ? Uncompressed ? Ashes ? > Now it is at the state of being all thrown to trashcan [...] > a new project will begin sometime next week .... Maybe you are giving up too fast. > I think it was that dreadful Calamares installer that came with this sid > distro that locks onto the disk and prevents ovewriting. I deem this unlikely. Your Linux was up and had control. Our problem is not about overwriting but about finding a directory path under which we can read the files of the USB stick partition. > But the usb was so hard locked that gparted would erase its partition, So you interspersed some other experiments ? That might be entertaining but also confusing. > > is it reported as two lines: > No it is all connected line [...] > > The reason why i ask is that i wonder from where xorriso has this > > strange two-line path. It would be explainable if you had given it to > > xorriso command "-map". > So are you saying the problem may lie in the name length that xorriso > can't handle? No. The name length should not be an obstacle until it reaches limits of the X/Open system specification (255 characters per name, 1024 per path). The problem is rather that xorriso gets to see a file path which does not lead to an existing file. Either this name stems from the program arguments of the run (i.e. is given after -map) or it stems from following a symbolic link, which tells a wrong target path. In the first case, the operator i(i.e. you) is to blame. In the second case, some automat installed confusing links. > the question I have is if this is ....part1 where is the other part/s? "part" shall mean "partition". I just wanted to keep the name short. > > New approach to get to a mount point of the stick: > xorriso : UPDATE : 116500 files added in 28 seconds > xorriso : FAILURE : Cannot open as source directory: > '/media/user/sid/lost+found' > ... > xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' We got some progress now. The new problem is the fact that xorriso (and possibly other user processes, too) cannot read the content of /media/user/sid/lost+found So why does this file make trouble ? IIRC, it is a directory which holds files that were found orphaned during filesystem checks. Please report the output of ls -ld /media/user/sid/lost+found (I will have to investigate why xorriso tells no further reason for being unable to read the directory's file list.) ------------------------------------------------------------------ Whatever, this is a local filesystem problem which we may try to circumvent by omitting the offending file object. xorriso \ -for_backup \ -outdev usb_part1.iso \ -not_paths /media/user/sid/lost+found -- \ -map /media/user/sid / The xorriso command -not_paths takes one or more file paths which then get excluded from the backup. The word "--" marks the end of this path list, so that the next word "-map" is then interpreted as next xorriso command. Let's see how far we will get with this try. If more unreadable "lost+found" directories show up, you may ban the name from being backed up when found under any path: xorriso \ -for_backup \ -outdev usb_part1.iso \ -not_leaf lost+found \ -map /media/user/sid / Other than -not_paths, -not_leaf takes exactly one parameter. So no end makr "--" is necessary. Have a nice day :) Thomas
