Re: [Libcdio-devel] About old branches of mine
Over the weekend I removed my stale branches from libcdio's git. On Fri, Mar 31, 2023 at 5:25 PM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein > > test/data/multi_extent_8k.iso| Bin 524288 -> 122880 bytes > > I think both versions should be there. We should be testing not just how > > things are created currently, but also how they may have been created in > > the past. > > I realize that i forgot to take into account your mail of > Mon, 27 Mar 2023 09:11:32 -0400. > > But actually i wanted to ask back why you want to keep an ISO which was > just created a bit wasteful for its purpose. > > It will never end up on a CD that gets written with write type TAO. Thus > it needs no 300 KiB of padding. > It will never be enlarged by multi-session. Thus a separate superblock > for the first session is not needed. > The goal in testing is to try all sorts of combinations that can occur. if xoriso or some other burner program in the past created ISO 9660 images in a particular way, then testing should be verifying that it can read those kinds of images. One can try to reason or argue that the exactly the same code path is taken in libiso9660, but it is possible to make a mistake, even if it is indeed the situation here. Better then is just to try both kinds of images. It is not like we are already testing a large number of images already. > The padding compensates for mislead reading ahead by Linux when the > drive firmware tells questionable read capacity which is invited by a bug > in the SCSI specs. > > The separate superblock would survive the writing of a next session and > stay mountable. Also it would be the starting point of the search for the > chain of session superblocks. xorriso command -toc can then tell a session > history like > ISO session : 1 ,32 , 2024199s , HOME_2022_07_07_155642 > ISO session : 2 , 2024256 , 26157s , HOME_2022_07_08_155953 > ISO session : 3 , 2050432 , 32162s , HOME_2022_07_09_151801 > ... > ISO session : 267 , 11491200 , 52690s , HOME_2023_03_30_193636 > ISO session : 268 , 11543904 , 44883s , HOME_2023_03_31_154321 > Media summary: 268 sessions, 11584524 data blocks, 22.1g data, 976m free > > Linux or libcdio are supposed to use the first superblock at LBA 0 which > always points to the newest session. So the old test ISO and the new one > are equivalent as far as libcdio is concerned. > If we keep the old ISO then there is no need to have the new one. It would > only be more waste of space. > > > Have a nice day :) > > Thomas > > >
Re: [Libcdio-devel] About old branches of mine
Hi, Rocky Bernstein wrote: > if xoriso or some other burner program in the past created ISO 9660 images > in a particular way, xorriso still produces the larger ISOs by default. Normally it does not matter to have 300+ KiB of waste, while the advantage is safety against the Linux TAO CD bug and the capability for recording a multi-session history. Whatever, do i get it right that you want me to add the old wasteful ISO to test/check_multiextent.sh like this ? for i in multi_extent_8k.iso \ multi_extent_8k_big.iso \ multi_extent_8k_joliet.iso do ... test ... Already finding a good name for the "_big" ISO is difficult. I am reluctant to call it "_wasteful" because it's waste only in the context of libcdio tests. "_old" would be wrong too, because it is still the default with xorriso. But "_default" would open the question what's wrong with it or with the other non-default ISO. It boils down to the fact that i cannot give a convincing motivation for its existence. A compromise would be to replace both by an ISO which just lacks the end padding but has the multi-session preparation: dd bs=2048 count=96 if=multi_extent_8k_big.iso \ of=multi_extent_8k.iso This would remove the end padding which is not counted as part of the ISO filesystem (other than results from the mkisofs emulation). The result has 196608 bytes rather than 524288. People might wonder why the ISO for the Joliet test is still smaller. Have a nice day :) Thomas
Re: [Libcdio-devel] About old branches of mine
On Mon, Apr 3, 2023 at 5:31 AM Thomas Schmitt wrote: > Hi, > > Rocky Bernstein wrote: > > if xoriso or some other burner program in the past created ISO 9660 > images > > in a particular way, > > xorriso still produces the larger ISOs by default. Normally it does not > matter to have 300+ KiB of waste, while the advantage is safety against > the Linux TAO CD bug and the capability for recording a multi-session > history. > > Whatever, do i get it right that you want me to add the old wasteful ISO > to test/check_multiextent.sh like this ? > > for i in multi_extent_8k.iso \ >multi_extent_8k_big.iso \ >multi_extent_8k_joliet.iso > do > ... test ... > > Yes, please do that. Thanks. > > Already finding a good name for the "_big" ISO is difficult. I am > It is not that difficult "_big" or if you want to be more correct "_larger" is fine. > reluctant to call it "_wasteful" because it's waste only in the context of > libcdio tests. "_old" would be wrong too, because it is still the default > with xorriso. But "_default" would open the question what's wrong with > it or with the other non-default ISO. > It boils down to the fact that i cannot give a convincing motivation for > its existence. > The motivation is that these are different. Even though xorriso doesn't create the smaller one some other burner might. > > A compromise would be to replace both by an ISO which just lacks the end > padding but has the multi-session preparation: > This feels like more complication than compromise. > > dd bs=2048 count=96 if=multi_extent_8k_big.iso \ > of=multi_extent_8k.iso > > This would remove the end padding which is not counted as part of the ISO > filesystem (other than results from the mkisofs emulation). The result has > 196608 bytes rather than 524288. > People might wonder why the ISO for the Joliet test is still smaller. > Add a README file inside the "test" that describes the images, what they are and how they were created. That would probably be a good thing to do anyway. > > Have a nice day :) > > Thomas > > >
Re: [Libcdio-devel] About old branches of mine
Hi, i pushed again branch "joliet_multi_extent" for review. The new commit re-introduces the old multi-extent test ISO as test/data/multi_extent_8k_emul_toc_padded.iso and a file test/README.multiextent which explains the differences between the now three multi-extent ISOs. I also solved the riddle why "make check" did not report anything about "check_multiextent.sh". Obviously i forgot to run ./autogen.sh after the test was added to test/Makefile.am. After doing what is precribed in README.develop i now see PASS: check_multiextent.sh Have a nice day :) Thomas
Re: [Libcdio-devel] About old branches of mine
Hi, Rocky Bernstein wrote: > Over the weekend I removed my stale branches from libcdio's git. I partly failed to do the same with a first deletion candidate. My cheat sheet says: git push origin --delete $branch_name When i do git push origin --delete api-doc i get the reply To scdbac...@git.sv.gnu.org:/srv/git/libcdio.git - [deleted] api-doc But "git branch" still lists it locally and https://git.savannah.gnu.org/cgit/libcdio.git/refs/heads was slow to delete it from its list. Well, meanwhile it is gone remotely. How can i get rid of it locally ? Have a nice day :) Thomas
Re: [Libcdio-devel] About old branches of mine
Hi, when trying to switch from branch "joliet_multi_extent" to "master" i was notified that a message text change did not make it into git. So i committed ab3ad52 Remove blanks from the test names in check_multiextent and pushed "joliet_multi_extent" again. Sorry for the confsion. Have a nice day :) Thomas
Re: [Libcdio-devel] About old branches of mine
Hi, i asked how to delete the local branch after deleting the remote one. The helpful internet told me to try git branch -d api-doc which did what i want. So i deleted more branches: trackno-higher-one pete_batard_gcc_warnings pete_batard_ce_v3 ts-multiextent pragmatic-multiextent By source code comparison with the commit diffs i verified that this branch somehow has been merged into "master": TS-RockRidge-Fix So i deleted it too. It did not exist locally, although it was attributed to me. The other unclear branch seems not to have made it into "master": ts-cdtext-fix I will send a separate mail about it. Have a nice day :) Thomas
[Libcdio-devel] Unmerged branch ts-cdtext-fix
Hi,
one of the unclear branches seems not to have made it into "master":
ts-cdtext-fix
I don't see traces of its commits (listed from oldest to newest):
6347ef09b6d1a6211b93425bd9b12b9d92b34e8c
Added comment to explain why function language_code_tests() exists
bde2647b444136e2d23d303d0a02d27383fcea32 (by Rocky)
Small typo caught by Thomas...
("Remove read-disc-struct binary" seems to have happened, though)
dd44e33a2756cdf6780e5aaab1f42dbfc8b60da9
Expanded maximum CD-TEXT payload size to 8 full text blocks of 256 * 18
bytes
53d38c7063c84c09c157441aad97934f603ef99f
Applied the proper destructor to CdioDataSource_t if parse_cuefile() sees
an undersized CDTEXTFILE
60ec2678d8f51196f4ec1e793ce55f7f99be9e7d
Enabled recognition and skipping of MMC headers before raw CD-TEXT data
388e859770724155b13da7fbdce7bfbb65adb104
Enabled recognition and skipping of MMC headers before CDTEXTFILE input in
.CUE files
They look like they would provide improvements. But it's nearly five years
ago that i was aware why i proposed those changes.
What would be the best strategy to evaluate it ?
Up to now i only verified that it merges without complaints with a test
branch freshly made from "master".
Strangely, the two oldest commits
bde2647b444136e2d23d303d0a02d27383fcea32
6347ef09b6d1a6211b93425bd9b12b9d92b34e8c
were not applied by
git merge 388e859770724155b13da7fbdce7bfbb65adb104
Both are mere comment corrections. Nevertheless i wonder what kept them
out.
Have a nice day :)
Thomas
Re: [Libcdio-devel] Unmerged branch ts-cdtext-fix
Hi, it looks like the two commits bde2647b444136e2d23d303d0a02d27383fcea32 6347ef09b6d1a6211b93425bd9b12b9d92b34e8c were overridden by newer changes. git merge bde2647b444136e2d23d303d0a02d27383fcea32 replied Already up-to-date. Closer inspection of the code shows that the removal of trailing blanks in bde2647b444136e2d23d303d0a02d27383fcea32 is in "master" and that the old text "Get binary CD-Text information for a CdIo_t object." is replaced by a three-liner which still has the wrong "for" which i want to change to "from". (I had expected that git merge sees this as noteworthy conflict.) The added comment lines of 6347ef09b6d1a6211b93425bd9b12b9d92b34e8c are not only missing, but the whole function language_code_tests() is gone. So the comment is not needed any more. Now i riddle how i could again bring my word change "for" -> "from" into file include/cdio/disc.h . Shall i wait until branch "ts-cdtext-fix" is reviewed and merged ? In my merge test branch, make check says: "PASS: cdtext" Have a nice day :) Thomas
Re: [Libcdio-devel] Unmerged branch ts-cdtext-fix
If there are not that many changes, it might be simpler just to start a new branch and add the changes you want there from the one where you are having a problem. On Mon, Apr 3, 2023 at 11:42 AM Thomas Schmitt wrote: > Hi, > > it looks like the two commits > bde2647b444136e2d23d303d0a02d27383fcea32 > 6347ef09b6d1a6211b93425bd9b12b9d92b34e8c > were overridden by newer changes. > > git merge bde2647b444136e2d23d303d0a02d27383fcea32 > replied > Already up-to-date. > > Closer inspection of the code shows that the removal of trailing blanks > in bde2647b444136e2d23d303d0a02d27383fcea32 is in "master" and that the > old text "Get binary CD-Text information for a CdIo_t object." is replaced > by a three-liner which still has the wrong "for" which i want to change to > "from". > (I had expected that git merge sees this as noteworthy conflict.) > > The added comment lines of 6347ef09b6d1a6211b93425bd9b12b9d92b34e8c are > not only missing, but the whole function language_code_tests() is gone. > So the comment is not needed any more. > > > Now i riddle how i could again bring my word change "for" -> "from" into > file include/cdio/disc.h . > Shall i wait until branch "ts-cdtext-fix" is reviewed and merged ? > > In my merge test branch, make check says: "PASS: cdtext" > > > Have a nice day :) > > Thomas > > >
Re: [Libcdio-devel] Unmerged branch ts-cdtext-fix
Hi, Rocky Bernstein wrote: > If there are not that many changes, it might be simpler just to start a new > branch and add the changes you want there from the one where you are having > a problem. It's just one word to change. So i will wait until the decisions about the two pending branches are made. - In "joliet_multi_extent" please check whether your wishes about the larger multi-extent test ISO are fulfilled. - In "ts-cdtext-fix" check whether you agree with commits dd44e33a2756cdf6780e5aaab1f42dbfc8b60da9 53d38c7063c84c09c157441aad97934f603ef99f 60ec2678d8f51196f4ec1e793ce55f7f99be9e7d 388e859770724155b13da7fbdce7bfbb65adb104 Have a nice day :) Thomas
