Re: xorriso: extracting files to stdout
Hi,
> l-wx------ 1 graud graud 64 Apr 17 0707:28 1 -> pipe:[17009189]
Strange link target. What does this mean ?
> I don't think you should try to guess what a user might want to do, even
> if it is legitimate to prevent misuse,
I have to stick to the principle of least surprise.
It is well standard among backup systems to remove the target by
unlink() before writing data to its new incarnation.
This does not only avoid symlink traps, but also restores the
file system tree as it was, with no influence by the intermediate
state that is undesirable enough to call for the backup.
> the chasing of symlinks [...] does not work
I will not have to lookup the link target myself.
But i have to decide whether the symlink shall survive
and its target shall be altered instead.
> > Do you see any use case where a regular data file should be
> > overwritten rather than being replaced ?
> if the directory permissions does not allow the user to remove/create
> files but a specific file was created for his use with the
> appropriate permissions to write to it.
That's a valid case, yes.
> Concatenating data streams by appending to a file (example:
> /VIDEO_TS/VTS_01_*.VOB on a DVD, similar to -paste_in I suppose).
If there is output to stdout or named pipes, then concatenation
will be available.
(-paste_in relies on random write access to the target file.)
> 4. Avoiding race conditions:
Interesting aspect. Looks like a valid case.
Is there any function for atomic unlink-and-create ?
> 5. Anything else that I could not guess.
That's not a valid case. :))
> > There remains the problem, that xorriso might also write text messages
> > to stdout, which would be hard to distinguish from file content.
> > A similar situation is given with ISO image output to stdout. Probably
> > i can derive safety precautions from that occasion.
> I do not understand what you mean by those sentences.
I already have a situation where messages and binary output compete
for stdout:
xorriso -outdev - ...commands...
In this case, i direct all stdout messages to stderr.
I will investigate whether this is appropriate for file extraction
to stdout, too.
> I would say the simplest way is to add a new command -cat
This has its appeal, yes. Something like
-cat file1 ... fileN target --
where target is allowed to be "-" for stdout.
This one could follow links, maintain existing file objects with
their attributes, refuse on target types which cannot take data,
The only problem is that it will not truncate data files to 0 size
before writing to them. (A hypothetical "-dd" could.)
So modifying settings for the existing extraction commands
will still be desirable.
> I would also suggest allowing to create pipes directly in xorriso for the
> convenience of users,
> [...] '|shell command string'
I am not very comfortable with this, currently.
Starting shell commands is extending the potential damage range
of xorriso. Well, there are the external filters already.
I soothed my scruples by adding configure options to ban them
and by disallowing them to setuid users by default.
(--disable-external-filters, --enable-external-filters-setuid)
... pondering ...
> I think having options to change the behaviour of -cpx, -extract etc. so
> that they accomodate what they find on the filesystem instead of adding
> -cat_r etc. would be another sensible choice.
That would be
- Follow symbolic links to replace or overwrite its target
rather than replacing the link itself.
- Do not unlink special files but rather overwrite their content
while keeping all their POSIX file attributes.
(What about ACL and getfattr attributes ?)
- Do not unlink regular files but handle them like the special
file in the previous option.
In case of no-unlink:
If the existing target file cannot take content because of file
type or permissions, then this is a failure event. The target
will not be replaced.
Special files from the ISO, which do not deliver content, will
not replace target files on disk but rather cause a failure event.
> In the case that symlinks are followed (or that they are not treated
> especially), why still unlink the destination (except possibly for non
> regular files on the iso)?
Because one may want its attributes to be replaced, or because
one wants new ctime, or becaue of reasons which we both don't
have in mind. :))
Actually its two different things, which i just want to keep
separate.
> This choice [of reaction on unfulfillable wextraction ishes]
> should match the spirit of xorriso however, and I do not know
> it very well.
The intended spirit is to be of help. :)
Too much eagerness might do more harm than good, though.
I will ponder over the easter holidays.
(Do you want a tarball for the new -find options to play with ?)
Have a nice day :)
Thomas
Reply to: