Re: Announcing xorriso-0.4.2
"Thomas Schmitt" <scdbackup@gmx.net> wrote:
> Joerg Schilling wrote:
> > What you implement may be a nice toy
>
> It is a backup format that can compete with
> programs like afio or star when it comes to
> fidelity of file properties.
> Its multi session capabilities allow fast
> and easy-to-use incremental backups.
Then please clealy mention that this are not ISO-9660 features and that you are
not creating a common standard exchange format. The backups are only readable
by the software that wrote it. If you correctly inform your users, this helps
your users to make a correct decision.
> > > * New option -md5, new -as mkisofs option --md5
>
> > Mkisofs does not have a -md5 option.
>
> Note the double dash with -as mkisofs --md5.
>
> There are some other extra options which help to
> beef up a mkisofs CLI client to backup grade quality.
>
> --quoted_path_list FILE File with list of quoted pathnames to process
> --hardlinks Record eventual hard link relations of files
> --acl Record eventual ACLs of files
> --xattr Record eventual user space xattr of files
> --md5 Compute and record MD5 checksums of data files
> --for_backup Use all options which improve backup fidelity
>
>
> > In case that mkisofs will eventually add a -md5 option, I cannot grant that
> > this option will be compatible to what you implement.....
>
> Now that you are aware of my --md5 it is
> your decision alone whether to implement
> a collision or not.
Single or double dash is not an issue. Iff I implement -md5, mkisofs will also
accest --md5 as documented since a long time for getargs().
If you have been interested in preventing a collision, you could have asked me
for a discussion _before_ you introduced such an option. I am always open to
good proposals. Now that you signalled that you are not interested in a unified
set of options, I cannot grnat anything for the future.
> ------------------------
>
> > > "cdrskin does not contain any bytes copied from cdrecord's sources."
> > This is not true. You even admit that
> > libburn/lec.c
> > is: .... borrowed HEAVILY from cdrdao.
>
> cdrdao is not cdrecord.
But cdrdao is based on code from cdrtools!
> Actually the code in lec.c was introduced
> by the founders of libburn under GPL.
> So they admit, not i.
What you have been told is something you need to discuss with the people you
collaborate with. The Copyright law requires you to name your code quotations.
It is always a problem with OpenSource that people may contribute code to you
that was written by others. This is why I am _very_ careful with contributions
and this is why I document where code comes from.
What we see again is that there is no OSS CD writing tool that is not based on
code from cdrtools.
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: