Hi,
I've started using libcdio on Windows, and I have found a couple of
memory leaks in the library. Please find a fix for the first ones, that
are localized in iso9660.
Regards,
/Pete
From cfe51293a1450202a0617e76a9120a6cb8b9a821 Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date
17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Mon, 16 Jan 2012 19:46:06 +
Subject: [PATCH 1/2] MinGW: detect if strndup is supported and add workaround
if not
---
configure.ac |4 ++--
lib/driver/abs_path.c | 15 +++
2 files changed, 17 insertions(+), 2
Another quick one.
Regards,
/Pete
From 2687f2acf7439365a1c45d84803f8d7211326972 Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Tue, 17 Jan 2012 12:56:59 +
Subject: [PATCH] Examples: fix unused variables warning
sample3.c: In function 'main':
sample3.c:148:9: warning
On 2012.01.17 15:43, Rocky Bernstein wrote:
Oh, I forgot to ask -- are we sure this is a bug in libcdio? It is possible
that it was valid at the time it was written for an earlier UDF standard.
Well, the first thing is that the reuse of udf_dirent_t on memcopy
without checking the size looks
On 2012.01.17 16:25, Rocky Bernstein wrote:
If you'd like to commit to the git repository, let me know your
savannah.gnu.org account.
Why not... ;) ID is pbatard.
Unless it's trivial stuff, I'll make sure people have had a chance to
comment/review patch proposals sent to this mailing list,
Makes it easier to spot warnings... and want to do something about them.
If Automake v1.10 or earlier is used, this will simply be ignored,
therefore this patch should be safe to apply.
Regards,
/Pete
From f94a4b8f4fcf4eb6544610b77b7752ee157d1a91 Mon Sep 17 00:00:00 2001
From: Pete Batard
Another quick one.
Regards,
/Pete
From 2687f2acf7439365a1c45d84803f8d7211326972 Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Tue, 17 Jan 2012 12:56:59 +
Subject: [PATCH] Examples: fix unused variables warning
sample3.c: In function 'main':
sample3.c:148:9: warning
/WindowsDeveloperPreview-64bit-English-Developer.iso
From 4616028005dfedc6580baa75d5390a9696921ffc Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Sun, 22 Jan 2012 02:00:37 +
Subject: [PATCH] Add ISO9660+UDF image extraction example
---
example/Makefile.am |5 +-
example/extract.c | 270
The next issue we probably want to fix at this stage is the one with the
buffer overflow (bug #22865), which can be displayed by adding some
instrumentation.
If you apply the attached patch, here is what you get:
(...)
Extracting: /mnt/data/test/sources/inf/setup.cfg
Extracting:
On 2012.01.23 01:47, Rocky Bernstein wrote:
To make it easier for others to test things out, I've created a pbatard
branch and committed the patch here and the next one to reset
_udf-i_position.
You can commit future changes to the pbatard branch, and then when folks
feel the time is read this
On 2012.01.23 15:03, Rocky Bernstein wrote:
Ok. Since I think it important, unless there are other volunteers I'll look
into adding tests for the very specific bugs that are encountered.
I very much appreciate that! And I'll try to help as much as I can.
To give you an idea of what's in
With the previous fix applied, the next issue we are facing is in
udf_read_sectors() and more specifically the fact that it uses 32 bit
values when ran on 32 bit systems, for i_byte_offset.
The i_byte_offset value is used with SEEK_SET, so it should always be
positive, however if you modify
On 2012.01.25 01:21, Rocky Bernstein wrote:
Just for curiosity, what does the Phillips UDF checker say about this if
anything?
It says that it's an ISO9660 image and that I should leave it alone,
because it's just a poor and lonesone UDF checker... ;)
More seriously, I looked on the Philips
The first hurdle we meet for MSVC support has to do with the above, and
the apparent lack of harmonization between using a (topdir)/config.h or
a cdio/cdio_config.h.
As a matter of fact, one of the first thing the make process has to do
is duplicate the toplevel config.h into
On 2012.01.26 23:09, Pete Batard wrote:
shouldn't we have all our config dependent files starting with:
#if defined(HAVE_CONFIG_H) !defined(__CDIO_CONFIG_H__)
#define __CDIO_CONFIG_H__ 1
#include config.h
#else
#if !defined(EXTERNAL_LIBCDIO_CONFIG_H)
#define EXTERNAL_LIBCDIO_CONFIG_H
#include
On 2012.01.27 03:48, Rocky Bernstein wrote:
I'm not sure that the rationale you understand is why those two are there.
cdio_config.h that you cite above is externally installed. It is available
for use in compilation before and after libcdio is installed. It forms the
API.
On the other hand
A few addons, for the sake of completion:
o A quick search for the other macros that don't begin with HAVE_ (such
as PACKAGE_###, AC_APPLE_UNIVERSAL_BUILD, etc) seem to indicate that
they aren't used in any of the API headers
o /include/cdio++ doesn't seem to use any of the cdio_config.h
As per previous posts, the -pbatard branch now has had the requirement
for cdio_config.h (and cdio_unconfig.h) removed [1].
With regards to its impact on the includes, I'm confident that the
dependency for stdbool.h/HAVE_STDBOOL_H should be pretty much squared
off (it's very straightforward
warrant an API
bump.
Regards,
/Pete
From c40dd3269e049611cc1f53e01b1d0bec0fb50957 Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Sun, 29 Jan 2012 17:15:50 +
Subject: [PATCH 1/3] ISO9660: fix iso9660.h header for MSVC compatibility
* MSVC compilers cannot handle a zero
a bit
of cleanup).
Regards,
/Pete
From 2331026997aa87ae14999cd91a13c2097c3e0122 Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Sun, 29 Jan 2012 17:07:23 +
Subject: [PATCH 3/3] Fix mmc_ll_cmds.c for use with MSVC compilers
* The MMC_CMD_SETUP() macro defines a new
On 2012.01.30 14:53, Robert Fuller wrote:
This brings up an important point. MSVC
does not support C99 and Microsoft has no stated plans to support it.
Unfortunately, that's absolutely true. That's also why trying to reuse
C99/GNU99 code in an MSVC project can be a major PITA.
Besides
Hi Robert,
On 2012.01.31 11:27, Robert William Fuller wrote:
Pete,
A flashback from my Windows NT driver writing days: I seem to recall
that MSVC will allow char str[0] here. You can have a zero-length
array at the end of a structure as long as the size is explicitly zero.
It's just done
On 2012.01.31 02:50, Rocky Bernstein wrote:
I meant to add one other small point which I think should be worth
mentioning.
In a project like libcdio the extent of its portability is determined
largely by those who use it and are willing to help out. At various times
in the past, the code has
On 2012.02.05 04:10, Rocky Bernstein wrote:
I think what really needed is a transformation of config.h which
prepends, say CDIO_ to a number of the defines like the PACKAGE* defines
and other defines like _FILE_OFFSET_BITS, _LARGEFILE_SOURCE and
WORDS_BIGENDIAN. With this, such a modified header
Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Fri, 10 Feb 2012 18:14:08 +
Subject: [PATCH 1/5] Improve configure.ac and update for MinGW
* use Define to as this is the comment default from autotools
* use quotes and x prefix for string tests
* add detection for MinGW required LFS
the attached one.
Regards,
/Pete
From a2313a7f90469e885fd86095deaa85508f6097d6 Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Fri, 10 Feb 2012 18:25:33 +
Subject: [PATCH 2/5] Add extract ISO/UDF example
* also add UDF test and remove testunconfig
* also remove some polluting
See previous mail.
Regards,
/Pete
From 7849938882c6356634f8454bc0ac632bfc0be7b1 Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Fri, 10 Feb 2012 18:32:43 +
Subject: [PATCH 4/5] Harmonize source headers: C examples
---
example/audio.c | 17
See previous mail.
Regards,
/Pete
From d50ac787ddcdf83b11172bf17cfdd55d6f53a3e3 Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Fri, 10 Feb 2012 18:39:29 +
Subject: [PATCH 5/5] Harmonize source headers: test sources
---
test/check_sizeof.c | 11
On 2012.02.12 14:53, Rocky Bernstein wrote:
I get a failure running the check_udf.sh created by this patch:
Well, there are some UDF patches missing from -pbatard, so the test is
not supposed to work at this stage. It is added so that we can check
that UDF extraction works _when_ it is
On 2012.02.13 07:33, Rocky Bernstein wrote:
Although I said in test-driven development, advocates suggest writing tests
first, so tests start out broken, by the time one commits code, the tests
should work.
Well, for UDF, that was pretty much the case. Test was broken and was
simply added so
On 2012.02.14 01:41, Rocky Bernstein wrote:
I will merge the various pbatard patches into master and write additional
tests as I can.
Thanks. I do appreciate that and I'll see what I can do to help, at
least to make sure that any additional tests are validated against MinGW.
So there is no
On 2012.02.20 12:45, Rocky Bernstein wrote:
There have a few larger unrelated changes that taken place and I would like
to solicit opinions on whether we should have one release with all of the
changes or two?
The changes are
* CD-Text completion (some incompatibility)
* UDF improvement and
On 2012.02.21 12:51, Rocky Bernstein wrote:
Since no other comments, looks like we'll go for one release with
everything.
Great.
As previously indicated, I'd still prefer to push bitesize set of
patches from what I have in my branch, for you to integrate, and I am
more or less waiting on
On 2012.02.22 15:35, Rocky Bernstein wrote:
Will try to move forward on this, this week.
OK. I'll try to remove paranoia from my branch soon.
Removing paranoia was mentioned last November
I see. Hopefully, since this is removal, it won't be too much of a
headache. Paranoia seems to be
On 2012.02.22 16:10, Nicolas Boullis wrote:
On a side note, please be aware that I had to apply a fix for the
commit from Nicolas (deprecation), since __attribute__ is known to
GNU only [1].
Once we're done with integration, libcdio may need to be more
mindful of GNUisms... ;)
Sorry for that.
On 2012.03.05 10:45, Rocky Bernstein wrote:
Just double checked. What was in master is what is currently in ecma_167.h
http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=blob;f=include/cdio/ecma_167.h;hb=89668c7d0e0877fa787c9464b6a57c18afda3624#l584
The union should include an udf_Uint16_t
On 2012.03.05 03:41, Rocky Bernstein wrote:
On another note, I see there are still paranoia related files in
src/cd-paranoia/ as well as a test/testparanoia.c. Shouldn't these be
removed as well?
Yes. I've made another scan and hopefully have removed all remnants now in
git.
I think I found
OK, pbatard-integration2 should now be pretty much in line with
-pbatard, short of additional patches that will be required for MSVC
project files (but those are fairly independent).
Unfortunately, the paranoia removal commits are a bit all over the
place, as I had connectivity issues today,
Getting into the final pieces of the puzzle now, with 4 more commits in
integration2.
The first one is yet another round of paranoia/unconfig removal (will we
ever see the end of those?).
Second mostly adds a statically linked version of the extract sample for
MSVC. Besides the actual MSVC
On 2012.03.09 02:09, Rocky Bernstein wrote:
We also modify the win32 cdrom driver files so that
1. It works with Visual Studio
2. It doesn't require end user applications to link with any additional
libraries beside the libcdio ones
I don't understand why this is a win in all cases. As you
On 2012.03.11 01:14, Rocky Bernstein wrote:
In all cases, considering that we only use 2 calls for winmm, we might as
well remove the need to specify that library during compilation.
I still don't understand the importance of this.
Very simple. A good library is one that saves time for its
On 2012.03.12 02:08, Rocky Bernstein wrote:
A lot of the concerns you have seem to be for people writing applications
(as opposed to end users).
Indeed. This is because those are compilation concerns, and I don't
exactly see how they relate to end-users. Some aspects of libcdio impact
On 2012.03.15 12:17, Rocky Bernstein wrote:
There is an assertion that if it were just that for one little file,
version.h, life would be so simple on MSVC in building from git. This may
be true, but only from a very limited point of view. And one I don't want
to promote.
Then you are probably
On 2012.03.18 04:07, Rocky Bernstein wrote:
Is the glass half empty or half full? Right now we don't *have* any MSVC
users, except yourself.
Indeed. And by the looks of it, it doesn't look like you're willing to
take any steps to encourage more MSVC users to use libcdio, by applying
a
On 2012.03.20 05:26, Rocky Bernstein wrote:
Over the 12 or more years, I have been more or less the only person working
on libcdio. There have been periods where others have come and contributed
greatly; but over time people disappear.
Yes, and this is true for every single FOSS project. This
On 2012.03.21 10:02, Rocky Bernstein wrote:
I am a convinced Linux user but imho as long as the projects using libcdio
like VLC are released for other systems we should try to do so, too. The
demand is there.
There are a couple of possible misunderstandings here.
Indeed there are. Please
On 2012.03.23 00:54, Rocky Bernstein wrote:
More central to the main point was this weird distortion:
Treating MSVC as a minor platform that can be brushed aside ...
I wondered for a while where that mis-impression comes from. I suppose is
it partly from the remark I made that perhaps not
Hi Natalia,
On 2013.10.21 22:52, Natalia Portillo wrote:
Do you have knowledge of VS precompilation scripts?
And postcompilation?
I've done some very limited work with Pre and Post build events in
VS2012 for libwdi, where I wanted Intellisense to avoid scanning a large
autogenerated
As promised.
This should produce the following when running make test:
-- Volume id: NEU
PASS: testudf
Regards,
/Pete
From d3705b04c06592e2a22834d146e5c653fae21264 Mon Sep 17 00:00:00 2001
From: Pete Batard p...@akeo.ie
Date: Tue, 29 Oct 2013 19:45:47 +
Subject: [PATCH] Add UDF test
with various options in ImgBurn, to see if
I could create an UDF image displaying the same symptoms, but no luck.
Regards,
/Pete
From fa369179f954e6f0592d9059914afae17c27844d Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Wed, 30 Oct 2013 18:25:31 +
Subject: [PATCH
.
The patch also contains an associated test as well as the required UDF
image (which was created using ImgBurn).
Regards,
/Pete
From 6310430dd712e9769e49dd942d2200cb27951cec Mon Sep 17 00:00:00 2001
From: Pete Batard pbat...@gmail.com
Date: Thu, 20 Feb 2014 02:21:27 +
Subject: [PATCH] Add
On 2014.02.22 00:06, Rocky Bernstein wrote:
Patch applied in commit 7029581
Thanks!
git-apply didn't work while patch mostly worked. So the test image test
hasn't been added. Add it as an attachment in
https://savannah.gnu.org/patch/?group=libcdio And please double check that
the changes are
On 2014.02.22 01:44, Rocky Bernstein wrote:
Great! Go for it.
Done.
I had to push an additional commit, because one of the applications you
used when saving and committing the patch wasn't smart enough to
recognise that testudf.c.in was using UTF-8 encoding, and trashed some
of its data in
Also use the common breakdown for calloc() parameters, add
a missing closing parenthesis in a log statement and NUL
terminate a string after the srtncpy() call.
From 5bcdab785eb41fa2379774a7434ac7774d9527a0 Mon Sep 17 00:00:00 2001
From: Pete Batard <p...@akeo.ie>
Date: Mon, 13 Mar 2017 11
Hi Rocky,
On 2017.03.13 12:47, Rocky Bernstein wrote:
Cursory look is fine. Since you have access to the libcdio repository, a
suggestion is to create a git branch and apply these changes there. Then we
will merge that in.
Done.
You'll find that a new 'pbatard-fixes' branch has been pushed
probably want to avoid the warning for extensions that we are already
aware of, even if we don't formally support them in libcdio.
Regards,
/Pete
[1] https://bugs.kali.org/view.php?id=4109
[2] https://en.wikipedia.org/wiki/Rock_Ridge
From e8289ce885e692dbbc64ec57da9bb879ffa7bcc8 Mon Sep 17 00:00:00 20
Hi Natalia,
On 2017.07.25 12:49, Natalia Portillo wrote:
If you create an interesting tool and/or structure specification whatever, YOU
CANNOT create the wikipedia page yourself,
Yes, I know about page creation. But we are talking about editing an
existing page to add content about an item
On 2017.07.25 12:49, Thomas Schmitt wrote:
That would be "original research" which Wikipedia forbids.
Hopefully, I shared my views on that in my other reply. ;)
I use the prepared extension opportunity of SUSP. Any SUSP compliant
software should have no problem with this.
Agreed.
Further
On 2017.07.25 17:44, Thomas Schmitt wrote:
Is there a way to approach moderators in advance ?
I would think there is, but I haven't gone through that exercise myself
(the interactions I've had were in reply to an edit, or through the user
page, which each Wikipedia contributor gets).
I
On 2017.07.25 21:34, Thomas Schmitt wrote:
I added my insight and suspicion now.
Maybe Raphael bothers to show me the code that controls the xorriso run.
Don't know about Raphael, but I certainly can do that now.
That code resides in a /usr/lib/live/build/binary_iso script, that one
gets
On 2017.07.26 15:34, Thomas Schmitt wrote:
So it is now unclear why Pete did not get the long Joliet names from libcdio,
which are quite the same as the Rock Ridge names.
I can answer that: In the application where I am seeing the issue, we
only call on iso9660_name_translate_ext() for Joliet
Hi,
Just gonna point out that I applied my own custom patch for multiextent
files in the custom libcdio version I use in Rufus.
I am *not* planning to post a reworked version of this patch for
libcdio, as I don't think there exists a good solution that can work
without breaking backward
Hi,
This is another issue that got reported by users of my libcdio-based
application Rufus: When trying to process the latest BlackArch ISO [1]
(An ISO-9660 image from an Arch Linux derivative), the file
'blackarch/x86_64/airootfs.sfs' appears to seen by libcio as 2 separate
files with the
Hi Thomas,
Thanks for the analysis.
If possible, I'd vote for modifying struct iso9660_stat_s to use
uint64_t (or anything that's going to be typedef'd to uint64_t when
LFS is enabled) so that libcdio users don't have to jump through hoops
to get the actual size of a > 4GB file.
Apart from
RN: Invalid directory stat at offset 510
---
Here's he long story how i came to above conclusion
Pete Batard wrote:
++ WARN: from_733: broken byte order
This comes from inline functioni
from_733_with_err (uint64_t p, bool *err)
in
include/cd
For the record, the bug with openSUSE has been filled as:
https://bugzilla.opensuse.org/show_bug.cgi?id=1094761
On 2018.05.26 21:36, Thomas Schmitt wrote:
This brings me to a potential problem with endianness:
return (UINT32_C(0x) & p);
I meanwhile understand that it is safe.
On a
u = (uint8_t *)
I should have compiled first before sending mail.
Have a nice day :)
Thomas
From a4155f014c640e6896a41205a0f997be8db33808 Mon Sep 17 00:00:00 2001
From: Pete Batard <p...@akeo.ie>
Date: Sun, 27 May 2018 22:27:27 +0100
Subject: [PATCH 1/2] Set from_723 and from_733 to
newlines maybe...
- You can also browse the content of this proposal online at:
http://git.savannah.gnu.org/cgit/libcdio.git/commit/?h=pbatard-multiextent=c93341a28bba1842d7df89d784951eccc18050ff
Regards,
/Pete
From c93341a28bba1842d7df89d784951eccc18050ff Mon Sep 17 00:00:00 2001
From: Pete
On 2018.06.06 21:00, Thomas Schmitt wrote:
I think that is unfortunate to break the old examples (and the API).
Yes. That's why this is an RFC, as I mostly picked what I did in Rufus,
where I didn't care about breaking the API. I was indeed hoping that we
could improve on my first approach.
Hi,
I took the liberty of pushing a commit that removes inlining for 2
specific Win32 static calls in driver/image/bincue.c and driver/image/nrg.c.
Considering that recent compilers are usually smart enough about
inlining what can be inlined, I don't think this removal should harm us any.
Hi Rocky,
On 2018.06.27 19:52, Rocky Bernstein wrote:
I have a question though - to everyone: What are thoughts around a release
schedule? What would a reasonable roadmap be?
Yeah, I wanted to touch about that.
As far as I'm concerned, I'm certainly not in a hurry to see a new
release of
Hi Thomas,
On 2018.07.14 11:42, Thomas Schmitt wrote:
i have (for now) completed the branches
ts-multiextent
pragmatic-multiextent
Great!
Pete, may i ask you to test pragmatic-multiextent in your programs
and with your ISO collection ?
For varied reasons, it may be a couple of
On 2018.07.08 14:52, Rocky Bernstein wrote:
I hope I am reiterating something that is consistent with consensus
opinion: the next release we go with the compatible ABI and Thomas'
changes.
Well, I guess I wasn't clear enough then, as I disagree with this approach.
My vote is to *NOT* apply
't have time to work further on it.
Thomas has offered to improve it, and seems to be vested in it, so my take
is that we go in that direction.
On Tue, Jul 10, 2018 at 6:01 AM, Thomas Schmitt wrote:
Hi,
Pete Batard wrote:
Then, as a pragmatic person, I vote for the "only add total_
On 2018.07.09 20:01, Thomas Schmitt wrote:
* Old iso9660_stat_t with only additional member .total_size, refusing on
multi-extent files with gaps. (I doubt we will find any such files in
the wild.) No ISO_MAX_MULTIEXTENT.
I still don't see how that would work unless we assume that all
On 2018.07.09 22:05, Thomas Schmitt wrote:
lsn_t extent_lsn;
...
extent_lsn = from_733 (p_iso9660_dir->extent);
/* Important: Test here with previous .total_size */
if (p_stat->total_size > 0) {
/* This is a follow-up extent. Check for a gap. */
if
On 2018.07.09 17:17, Thomas Schmitt wrote:
The reader from ISO directory records, _iso9660_dir_to_statbuf(), knows
the start and size of the previous extent. So it could check whether the
current extent fits seamlessly.
E.g. after:
p_stat->extent_lsn[p_stat->num_extents] = from_733
Hi,
I got an issue reported today from a user trying to use a Rock Ridge ISO
with folders that go more than 8 levels, and it appears that the Rock
Ridge extensions from libcdio do not support RRIP Deep Directories, as
described on pages 33-34 of
.start_lsn,
p_msf);
return true;
}
}
Since it's your patch, I'll let you push it to master.
Many thanks for fixing this one!
Regards,
/Pete
PS: I also pushed an unrelated small commit for testischar.c, some time ago.
On 2020.05.20 18:08, Thomas Schmitt wrote:
Hi,
Pete Batard wrote in &quo
On 2020.05.20 14:35, Rocky Bernstein wrote:
On Wed, May 20, 2020 at 6:56 AM Pete Batard wrote:
Therefore, unless someone objects to removing the symlink and simply
duplicating cdda.bin as cdda_4_5.bin, I will push a commit that does
just that within the next 24 hours.
I'm okay
Hi,
First of all, I'm going to notify that I just pushed two small
straightforward patches to fix:
1. The size report of cd-info that was broken
2. The check_opts.sh test on MinGW (turns out that grep really doesn't
to see a CRLF in a regexp line).
I hope that this is okay.
Second, I'm
On 2020.05.20 22:17, Thomas Schmitt wrote:
Pete, if you can checkout branch "win32_first_tno_fix" (*) then it would
be nice to get a confirmation that i got my version of win32.c on the
second try by copy+paste of your corrected code.
(First commit of the branch was my faulty proposal by
(Re-sent to CC the mailing list)
On 2020.05.21 08:30, Thomas Schmitt wrote:
Pete Batard wrote:
I would advise to combine the 2 commits into a single one before merging,
That's reasonable. But how to do it without invalidating your testing?
That's called squashing. You should be able
On 2020.05.22 20:06, Thomas Schmitt wrote:
A small ISO with artificially small extents is available at
http://scdbackup.webframe.org/multi_extent_8k.iso.gz
Thanks Thomas.
I have now added a multiextent test to the 'pragmatic-multiextent-2020'
branch.
It's basically a set of 2 tests:
-
Hi Thomas,
On 2020.05.22 16:21, Thomas Schmitt wrote:
Pete Batard wrote:
That's called squashing. You should be able to find plenty of help on how to
do that using git rebase, such as https://gist.github.com/jbub/5766366
Ok. I'm now squashed at git push.
Question is whether i should push
Hi,
Thanks to you both for following up on multiextent. I realize I probably
should have spent a bit more time finalizing the proposal, as there were
indeed a few missing items.
On 2020.05.25 10:41, Rocky Bernstein wrote:
On Mon, May 25, 2020 at 4:23 AM Thomas Schmitt wrote:
Further we
Oh, and I just fixed another regular mishap that comes from using git on
Windows, in that check_multiextent.sh was missing the +x attribute...
/Pete
On 2020.05.24 20:48, Pete Batard wrote:
On 2020.05.24 17:00, Rocky Bernstein wrote:
On Sun, May 24, 2020 at 9:36 AM Thomas Schmitt wrote:
Hi
On 2020.05.24 17:00, Rocky Bernstein wrote:
On Sun, May 24, 2020 at 9:36 AM Thomas Schmitt wrote:
Hi,
branch pragmatic-multiextent-2020 has now passed all my experiments
which master would pass.
Insofar i propose to merge it.
Merge it then, unless anyone objects.
Okay, I applied the
On 2020.05.22 17:24, Rocky Bernstein wrote:
Sure - push directly to master. Thanks.
Done. Thanks.
/Pete
Hi,
Now that we are at a stage where that can happen, please be aware that I
have created new branch 'pragmatic-multiextent-2020', in the hope that
it can be merged into master.
If you recall the discussions from a couple years ago, there was debate
about what approach we wanted to go with,
On 2020.05.22 18:52, Thomas Schmitt wrote:
remote: error: denying non-fast-forward refs/heads/win32_first_tno_fix (you
should pull first)
Yeah, that error is typical of git repos where you can't use force to
push changes.
On one hand, not allowing force ensures that people who cloned
On 2020.05.22 19:26, Thomas Schmitt wrote:
Now i should look for the tests which i did with pragmatic-multiextent
(in part while it was much like pbatard-multiextent2).
Hopefully i can give some report until sunday evening.
Sounds good, thanks for doing that.
Considering that we've waited a
Hi Thomas,
Thanks a lot for looking into this.
I can understand why you are being confused, and I guess I have to
apologize for making you waste your time here, because it turns out that
the real issue is that cdda_4_5.bin was registered in git as a symbolic
link to cdda.bin, which of course
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,
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,
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
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
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
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
1 - 100 of 144 matches
Mail list logo
