Re: Announcing xorriso-0.4.0
"Thomas Schmitt" <scdbackup@gmx.net> wrote:
> Joerg Schilling wrote:
> > Did you verify correct behavior of the hard link support ?
>
> Within libisofs and xorriso it behaved plausible
> and stable in my tests.
What does this prove?
> The Linux kernels of recent years re-compute the
> inode number from the ECMA-119 directory record's
> byte address but read struct stat.st_ino from the
> Rock Ridge PX entry of the directory record.
> So one will see the intended link count but not
> the intended inode numbers in a mounted isofs.
Linux copied the inode algorithm that was introduced
by SunOS in 1988. This algorithm is not useful for larger
filesystems. I added a correct implementation to Solaris in
August 2006. Did you test against this implementation?
> This will prevent cp -a from recognizing the
> hard link relations.
cp does not have a -a option.
If you like to verify correct behavior, call
star -dump -c -C dir . > test.tar
and to verify on Solaris:
star -diff -v -C /mnt < test.tar
> But as with ACL and xattr, xorriso is able to
> restore what it recorded.
>From an earlier mail exchange, I know that you implemented
a proprietary and untested implementation for a ACL method
that was withdrawn 10 years ago. In additionm, you seem to
implement a non-standard xattr system.
Wouldn't it be better to implement support for the current standard that is
part of the NFSv4 standard
http://www.ietf.org/rfc/rfc3530.txt
There is a description of the ACL and the xatte standard inside....
> After adding reliable recording of hard link
> relations, i now deem xorriso to provide a very
> high backup fidelity.
If you did not verify this, how can you tell?
Why don't you just use mkisofs that has a correct implementation?
> Its basic archive format is documented in
> two layers: as ECMA-119 (can be read by DOS)
> and as RRIP-1.10 resp. RRIP-1.12 (can be
> read by X/Open systems).
> Its extension format for ACL and xattr is
> documented as
> http://libburnia-project.org/wiki/AAIP
See above: a proprietary implementation for a draft that
was withdrawn 10 years ago.
This is not what we need in the OSS world.
> > Why do ou try to pretend that there is libfind support
>
> Do i ?
>
> > without supporting a real find(1) command line?
>
> xorriso's option -find is inspired by program
> find. It implements a subset of its gestures and
> it adds specific extensions.
You try to cause the impression that you are using libfind but you don't.
You have been inspired by star and mkisofs that use libfind since many years.
It is bad practice to take an idea but not to implement it in a compatible way.
Why do you try to reinvent the wheel in a non-compatible way instead of
collaborating?
Why don't you just use libfind?
The last time I checked your source, the -find implementation was not even
remotely close to the find(1) POSIX standard. If you like to get find features,
use libfind. If you like to implement squared wheels, why don't you use
different options that clearly show the incompatibility?
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Reply to: