Should be fixed now. Sorry for the delay.
Regards,
/Pete
On 2020.06.18 09:39, Thomas Schmitt wrote:
Hi,
Pete Batard wrote:
I'm pretty sure this is because we don't have a .in to generate the .sh
The complaints are about the "rightfile" parameter $3 of function
test_iso_read, not about the
Hi,
Pete Batard wrote:
> I'm pretty sure this is because we don't have a .in to generate the .sh
The complaints are about the "rightfile" parameter $3 of function
test_iso_read, not about the scripts which do the tests.
I understand the test shall compare a freshly extracted file with a
file from
Hi Rocky,
On 2020.06.17 20:08, Rocky Bernstein wrote:
Thanks for doing the work and for merging.
I just ran "make distcheck" (building outside of source directory from a
tarball) and I get a couple of failures:
...
FAIL: check_multiextent.sh
PASS: check_fuzzyiso.sh
PASS: check_opts.sh
FAIL: ch
Thanks for doing the work and for merging.
I just ran "make distcheck" (building outside of source directory from a
tarball) and I get a couple of failures:
...
FAIL: check_multiextent.sh
PASS: check_fuzzyiso.sh
PASS: check_opts.sh
FAIL: check_deep_directory.sh
>From check_deep_directory.sh.log
Okay, I have just merged the proposal to mainline, with Thomas' proposed
improvement.
I validated that the test suite passed for both Windows/MinGW and Linux,
but of course, feel free to confirm that you don't see any issues.
Regards,
/Pete
On 2020.06.16 17:47, Thomas Schmitt wrote:
Hi,
R
Hi,
Rocky Bernstein wrote:
> But,Thomas, if you want to redo so it is smaller that's okay too.
We tested. We discussed. Let's merge.
Have a nice day :)
Thomas
Hi,
> I hope that it's okay.
Indeed. As soon as compression is involved, the bloat by lots of zeros
should not matter.
Have a nice day :)
Thomas
On 2020.06.16 17:31, Rocky Bernstein wrote:
But,Thomas, if you want to redo so it is smaller that's okay too.
Yes, I'm okay with that too. But the problem is the test comparison,
which includes file creation dates, would likely need to be redone, so
it's just not time spent re-creating the IS
But,Thomas, if you want to redo so it is smaller that's okay too.
On Tue, Jun 16, 2020 at 12:30 PM Rocky Bernstein wrote:
> Ok. I let's just go with the existing image.
>
> On Tue, Jun 16, 2020 at 12:04 PM Pete Batard wrote:
>
>> On 2020.06.16 15:48, Thomas Schmitt wrote:
>> > But if it is for
Ok. I let's just go with the existing image.
On Tue, Jun 16, 2020 at 12:04 PM Pete Batard wrote:
> On 2020.06.16 15:48, Thomas Schmitt wrote:
> > But if it is for size, then the existing
> >test/data/deep-directory.iso
> > is too large by the traditional padding of 150 * 2048 bytes (which is
On 2020.06.16 15:48, Thomas Schmitt wrote:
But if it is for size, then the existing
test/data/deep-directory.iso
is too large by the traditional padding of 150 * 2048 bytes (which is
needed only if the ISO gets onto a CD by write type TAO from which it
shall be read by the Linux kernel's block
Hi,
Rocky Bernstein wrote:
> If you both agree that they do the same thing then it is fine to have
> one. Thomas?
It's ok for me. I made my own one mainly to not just repeat the tests
which Pete already had made and to check whether xorriso's rarely used
deep directory relocation still works prop
On Tue, Jun 16, 2020 at 9:46 AM Pete Batard wrote:
> On 2020.06.16 14:03, Rocky Bernstein wrote:
> > Oh also, I don't see that Thomas' additional CD-images to test this are
> in
> > there. Should they be used?
>
> Do we need two test images?
>
> I've already added one in
>
> http://git.savannah.g
On 2020.06.16 14:03, Rocky Bernstein wrote:
Oh also, I don't see that Thomas' additional CD-images to test this are in
there. Should they be used?
Do we need two test images?
I've already added one in
http://git.savannah.gnu.org/cgit/libcdio.git/commit/?h=rr-deep-directory&id=6fa9723f4d920bc7
Oh also, I don't see that Thomas' additional CD-images to test this are in
there. Should they be used?
On Tue, Jun 16, 2020 at 9:01 AM Rocky Bernstein wrote:
> You have green light to do whenever you want.
>
> If you are done and would like me to test before merge, I can do that too.
>
>
>
> On
You have green light to do whenever you want.
If you are done and would like me to test before merge, I can do that too.
On Tue, Jun 16, 2020 at 7:50 AM Pete Batard wrote:
> On 2020.06.14 09:03, Thomas Schmitt wrote:
> > i think the changes for RR Deep Directory Relocation work fine and shoul
On 2020.06.14 09:03, Thomas Schmitt wrote:
i think the changes for RR Deep Directory Relocation work fine and should
be merged into master.
Thanks for testing. I'll wait for Rocky's green light before I do that.
Regards,
/Pete
On 2020.06.14 08:23, Thomas Schmitt wrote:
This would be clearer if the test would be in the reuse case of
/* Reuse multiextent p_stat if not NULL */
if (!p_stat) {
p_stat = calloc(1, stat_len);
first_extent = true;
} else {
+ /* Ignore Rock Ridge Deep Directory RE entries *
Hi,
i think the changes for RR Deep Directory Relocation work fine and should
be merged into master.
Congrats to Pete.
--
Test made:
I found an old directory tree on my hard disk which provokes double
deep relocation:
/1
/
Hi,
Pete Batard wrote:
> Technically we could have a non NULL last_p_stat
This would be clearer if the test would be in the reuse case of
/* Reuse multiextent p_stat if not NULL */
if (!p_stat) {
p_stat = calloc(1, stat_len);
first_extent = true;
} else {
+ /* Ignore Rock Ridge D
Hi Thomas,
I'm happy to see you are doing better now. :)
On 2020.06.13 13:16, Thomas Schmitt wrote:
just to show that i began to review the Rock Ridge Deep Directory code,
Thanks!
i wonder why the RR-related code snippet in lib/iso9660/iso9660_fs.c
line 832 is not surrounded by #ifdef HAVE_
Hi,
just to show that i began to review the Rock Ridge Deep Directory code,
i wonder why the RR-related code snippet in lib/iso9660/iso9660_fs.c
line 832 is not surrounded by #ifdef HAVE_ROCK and how a freshly calloc'ed
p_stat shall have (p_stat->rr.u_su_fields & ISO_ROCK_SUF_RE) true.
Further i
Hi,
Pete Batard wrote:
> I have just completed my RR deep directory support proposal, which can
> be found in the new rr-deep-directory branch I just pushed.
For now i can say that it compiles on my elderly Debian GNU/Linux.
But review might have to wait a few days, because i am not in good heal
Wow!
I will look and try the code when I get a chance.
Thanks!
On Sat, May 30, 2020 at 8:43 AM Pete Batard wrote:
> Hi,
>
> I have just completed my RR deep directory support proposal, which can
> be found in the new rr-deep-directory branch I just pushed.
>
> Support for deep directory has b
Hi,
I have just completed my RR deep directory support proposal, which can
be found in the new rr-deep-directory branch I just pushed.
Support for deep directory has been added in a transparent manner, so
that, as long as an ISO image has been opened with
ISO_EXTENSION_ROCK_RIDGE, no alterat
25 matches
Mail list logo
