Hi, i see some ISO 9660 and/or Rock Ridge problems in FreeBSD-11.0-CURRENT-amd64-20151001-r288459-disc1.iso from http://ftp.freebsd.org/%2Fpub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/ Garrett Cooper told me on freebsd-hackers@freebsd.org that this ISO was made by https://svnweb.freebsd.org/base/head/release/amd64/mkisoimages.sh?view=log with backend makefs. I assume that the source at https://svnweb.freebsd.org/base/head/usr.sbin/makefs/ is the one in effect. He advised me to file a PR with "CC re@". I deem the problems closely related enough for sharing one PR. Please give me a note if i shall re-submit as separate PRs. Overview: 1: Uninitialized malloc memory in timestamp of root directory. 2: Timestamp of "/bin" differs from timestamp of "/bin/." 3: Rock Ridge timestamp entry TF shows atime as Creation Time and ctime as Access Time. 4: Directories with all uppercase names get shown as lowercase on Linux. =================================================================== Problem 1: Uninitialized malloc memory in timestamp of root directory. The root directory entry and also "/." show as "Recording Date and Time" the 7-byte string {165, ..., 165}, which except for the first byte violates ECMA-119 9.1.5. It restricts bytes 1 to 5 to reasonable values for month, day_of_month, hour, minute, second. Byte 6 shall be in the range of -48 to +52, whereas 165 as signed 8-byte value is -91. --------------- Source analysis: usr.sbin/makefs/cd9660.c : cd9660_populate_iso_dir_record() does not set a default value for record->date Function cd9660_translate_node_common() does after the populate call: /* If we want to use the current date and time */ time(&tim); cd9660_time_915(newnode->isoDirRecord->date, tim); The function usr.bin/makefs/cd9660/cd9660_conversion.c : cd9660_time_915() looks like an implementation of ECMA-119 9.1.5, the appropriate format for record->date. Function cd9660_setup_root_node() does not make such a call for diskStructure.rootNode->isoDirRecord->date --------------- Remedy proposal: Move the default timestamp code from cd9660_translate_node_common() to cd9660_populate_iso_dir_record(). =================================================================== Problem 2: Timestamp of "/bin" differs from timestamp of "/bin/." The Rock Ridge equipment of directory records of directories in their parent directory differs from the equipment of "." records in their own directory. E.g. "/bin" differs from "/bin/." not only by name. "/bin" has Rock Ridge entry TF, which gives timestamps. (At 2048-block 842 + offset 584 bytes) "/bin/." has no TF. (At 2048-block 844 + offset 0) The content of TF's Creation Time {115 10, 1, 21, 36, 58, 0} differs from the content of the ECMA-119 record fields {115, 10, 1, 21, 38, 24, 0} --------------- Source analysis: usr.sbin/makefs/cd9660/iso9660_rrip.c : cd9660_rrip_initialize_node() has special handling for CD9660_TYPE_DOT and CD9660_TYPE_DOTDOT, which only appends PX entries. Other nodes get treated by cd9660_rrip_initialize_inode(), which appends TF. --------------- Remedy proposal: Add adapted copies of the TF producer from cd9660_rrip_initialize_inode(): /* TF - timestamp */ attr = cd9660node_susp_create_node(SUSP_TYPE_RRIP, SUSP_ENTRY_RRIP_TF, "TF", SUSP_LOC_ENTRY); cd9660node_rrip_tf(attr, node->node); TAILQ_INSERT_TAIL(&node->head, attr, rr_ll); to the cases in cd9660_rrip_initialize_node(): if (node->type & CD9660_TYPE_DOT) { ... if (parent != NULL && parent->node != NULL && parent->node->inode != NULL) { /* PX - POSIX attributes */ current = cd9660node_susp_create_node(SUSP_TYPE_RRIP, SUSP_ENTRY_RRIP_PX, "PX", SUSP_LOC_ENTRY); cd9660node_rrip_px(current, parent->node); TAILQ_INSERT_TAIL(&node->head, current, rr_ll); /* TF - timestamp */ current = cd9660node_susp_create_node(SUSP_TYPE_RRIP, SUSP_ENTRY_RRIP_TF, "TF", SUSP_LOC_ENTRY); cd9660node_rrip_tf(attr, parent->node); TAILQ_INSERT_TAIL(&node->head, current, rr_ll); } } else if (node->type & CD9660_TYPE_DOTDOT) { if (grandparent != NULL && grandparent->node != NULL && grandparent->node->inode != NULL) { /* PX - POSIX attributes */ ... TAILQ_INSERT_TAIL(&node->head, current, rr_ll); /* TF - timestamp */ current = cd9660node_susp_create_node(SUSP_TYPE_RRIP, SUSP_ENTRY_RRIP_TF, "TF", SUSP_LOC_ENTRY); cd9660node_rrip_tf(attr, grandparent->node)); TAILQ_INSERT_TAIL(&node->head, current, rr_ll); } /* Handle PL */ =================================================================== Problem 3: Rock Ridge timestamp entry TF shows atime as Creation Time and ctime as Access Time. The Rock Ridge TF entries indicate Creation Time rather than Last Attribute Change Time. RRIP-1.12 says: "If recorded, CREATION, Creation Time, has the same meaning as in ISO 9660:9.5.4." "If recorded, ATTRIBUTES, Last Attribute Change Time, shall be used for the st_ctime field of POSIX:5.6.1." ECMA-119 (aka ISO 9660): "9.5.4 File Creation Date and Time (BP 11 to 27) This field shall specify the date and the time of the day at which the information in the file was created." So for recording ctime, the FreeBSD ISO seems to use the wrong TF field. (I write "seems" because it is actually worse than that.) --------------- Source analysis: TF is composed in usr.sbin/makefs/cd9660/iso9660_rrip.c : cd9660node_rrip_tf() The TF Flags value is composed as p->attr.rr_entry.TF.flags[0] = TF_MODIFY | TF_ACCESS | TF_ATTRIBUTES; which on the first glimpse looks ok. But usr.sbin/makefs/cd9660/iso9660_rrip.h has wrong values for the macros #define TF_CREATION 0x00 #define TF_MODIFY 0x01 #define TF_ACCESS 0x02 #define TF_ATTRIBUTES 0x04 According to RRIP-1.12 Table 5 the defines should be #define TF_CREATION 0x01 #define TF_MODIFY 0x02 #define TF_ACCESS 0x04 #define TF_ATTRIBUTES 0x08 The timestamps atime, mtime, ctime are then written in wrong order so that at least mtime ends up where a mounter would expect it with the wrong flags value 0x07. ctime and atime are wrongly positioned even for a very tolerant reader like the Linux kernel. RRIP-1.12 prescribes to write the values in the order of the flags bits. I.e.: creation_time, mtime, atime, ctime, ... --------------- Remedy proposal: In usr.sbin/makefs/cd9660/iso9660_rrip.h define #define TF_CREATION 0x01 #define TF_MODIFY 0x02 #define TF_ACCESS 0x04 #define TF_ATTRIBUTES 0x08 and in usr.sbin/makefs/cd9660/iso9660_rrip.c rearrange the three time stamp values to cd9660_time_915(p->attr.rr_entry.TF.timestamp, _node->inode->st.st_mtime); ... cd9660_time_915(p->attr.rr_entry.TF.timestamp, _node->inode->st.st_atime); ... cd9660_time_915(p->attr.rr_entry.TF.timestamp, _node->inode->st.st_ctime); ... =================================================================== Problem 4: Directories with all uppercase names get shown as lowercase on Linux. Some files have Rock Ridge NM fields, some don't. The NM field records the case sensitive long name of the file. Having none makes the file name prone to mapping when it gets shown by reader software. Typical mappings are: - Removal of trailing ".;1" or ";1". - Presentation as lowercase characters. Missing are the NM fields of the directories in /usr/share/i18n/csmapper (At 2048-block 323995) /usr/share/i18n/esdb (At 2048-block 338174) and of the directory "C" in /usr/share/nls (At 2048-block 353273) The regular files in the same directories do have NM. --------------- Source analysis: usr.sbin/makefs/cd9660/iso9660_rrip.c : cd9660_rrip_initialize_node() has the following conceptual mistake: /* * Not every node needs a NM set - only if the name is * actually different. IE: If a file is TEST -> TEST, * no NM. test -> TEST, need a NM * * The rr_moved_dir needs to be assigned a NM record as well. */ This explains why only directories are affected. Names of regular files get appended a dot ".", if there is none in the name, plus text ";1" as "Version Number". As mentioned above, the lack of NM invites name mapping. E.g. the kernel of Linux by default maps ECMA-119 names to lowercase. FreeBSD 8.0 (antique) and NetBSD 6.99 (of last year) show uppercase, although man mount_cd9660 of NetBSD indicates otherwise in its text about "-o gens". --------------- Remedy proposal: Unconditionally call cd9660_rrip_NM(node); for all nodes which are not CD9660_TYPE_DOT or CD9660_TYPE_DOTDOT. =================================================================== Have a nice day :) Thomas
All four problems are present in NetBSD's makefs, too. =================================================================== Problem 1: Uninitialized malloc memory in timestamp of root directory. http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/makefs/cd9660.c?annotate=1.49 The function cd9660_populate_iso_dir_record (line 733) looks exactly like in FreeBSD. cd9660_setup_root_node() does not set a date, whereas cd9660_translate_node_common() does. =================================================================== Problem 2: Timestamp of "/bin" differs from timestamp of "/bin/." http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/makefs/cd9660/iso9660_rrip.c?annotate=1.11.2.2 380: if (node->type & CD9660_TYPE_DOT) { ... no TF ... 397: } else if (node->type & CD9660_TYPE_DOTDOT) { ... no TF ... 413: } else { 414: cd9660_rrip_initialize_inode(node); =================================================================== Problem 3: Rock Ridge timestamp entry TF shows atime as Creation Time and ctime as Access Time. http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/makefs/cd9660/iso9660_rrip.h?annotate=1.5.8.1 51: #define TF_CREATION 0x00 52: #define TF_MODIFY 0x01 53: #define TF_ACCESS 0x02 54: #define TF_ATTRIBUTES 0x04 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/makefs/cd9660/iso9660_rrip.c?annotate=1.11.2.2 690: p->attr.rr_entry.TF.flags[0] = TF_MODIFY | TF_ACCESS | TF_ATTRIBUTES; ... 700: _node->inode->st.st_atime); ... 704: _node->inode->st.st_mtime); ... 708: _node->inode->st.st_ctime); =================================================================== Problem 4: Directories with all uppercase names get shown as lowercase on Linux. http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/makefs/cd9660/iso9660_rrip.c?annotate=1.11.2.2 417: * Not every node needs a NM set - only if the name is 418: * actually different. IE: If a file is TEST -> TEST, 419: * no NM. test -> TEST, need a NM ===================================================================
Handing a number of makefs, mtree, and msdosfs bugs in my queue over to emaste@.
Reset assignee - I am not currently looking at this PR.
Problem 3: https://reviews.freebsd.org/D39221 To the reporter, please let me know what name I should use for "Reported by:" or "Submitted by:" if desired.
Hi, Ed Maste wrote: > Problem 3: https://reviews.freebsd.org/D39221 > To the reporter, please let me know what name I should use for > "Reported by:" or "Submitted by:" if desired. Reported by: Thomas Schmitt <scdbackup@gmx.net> It's a while ago that i looked into this problem. Said this, the diff looks good to me. -------------------------------------------------------------------- About the NM flags problem: NM_PARENT is mentioned in the disabled code as if it should be 0x04 (RRIP 1.12 1.1.4 "NM"). It seems beneficial that the code is disabled, which tries to use it. The flag means that the NM entry describes the parent directory of the directory in which the NM entry is attached to a file. (But i riddle how the ISOs get their NM entries when cd9660node_rrip_nm() is disabled. I see NMs in FreeBSD-12.0-RELEASE-amd64-bootonly.iso .) Have a nice day :) Thomas
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c65c969bd5d4ae7c52dedafb3c39b7e933079d4a commit c65c969bd5d4ae7c52dedafb3c39b7e933079d4a Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-03-22 23:42:45 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-03-23 11:11:58 +0000 makefs: correct iso9660 Rock Ridge TF timestamps The bit definitions for the TF_* timestamp bits (TF_MODIFY, etc.) were incorrect, and timestamps were written in the wrong order. See RRIP 4.1.6 Description of the "TF" System Use Entry for details. PR: 203531 Reported by: Thomas Schmitt <scdbackup@gmx.net> Reviewed by: jrtc27, kevans Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39221 usr.sbin/makefs/cd9660/iso9660_rrip.c | 4 ++-- usr.sbin/makefs/cd9660/iso9660_rrip.h | 16 ++++++++-------- 2 files changed, 10 insertions(+), 10 deletions(-)
Thanks Thomas and sorry that it took so long to get to this report. I hope that we'll be able to address the remaining issues soon.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c3ec19359e05c3b609e461896aa6ab4d6ad8121f commit c3ec19359e05c3b609e461896aa6ab4d6ad8121f Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-03-23 12:35:34 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-03-23 12:36:15 +0000 makefs: correct iso9660 Rock Ridge NM values These are not actually used by makefs (yet), but ought to match the spec. See RRIP 4.1.4 Description of the "NM" System Use Entry for details. PR: 203531 Sponsored by: The FreeBSD Foundation usr.sbin/makefs/cd9660/iso9660_rrip.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9f2a525360473a778f91021e3be58fd4bfd72ee5 commit 9f2a525360473a778f91021e3be58fd4bfd72ee5 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-03-23 17:02:44 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-03-23 21:56:33 +0000 makefs: correct El Torito bood record The boot catalog pointer is a DWord, but we previously populated it via cd9660_bothendian_dword which overwrote four unused bytes following it. See El Torito 1.0 (1995) Figure 7 for details. PR: 203531 Reported by: Coverity Scan Reported by: Thomas Schmitt <scdbackup@gmx.net> Reviewed by: kevans CID: 977470 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39231 usr.sbin/makefs/cd9660/cd9660_eltorito.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
> Unconditionally call > > cd9660_rrip_NM(node); > > for all nodes which are not CD9660_TYPE_DOT or CD9660_TYPE_DOTDOT. We could get away with omitting the NM for files that can't be misrepresented I believe (e.g. a file named 1234.567), but I'm not sure it's worth the effort.
Hi, i am watching the progress of this PR and agree with the commit changesets so far. But i think that the reason to commit https://cgit.freebsd.org/src/commit/?id=9f2a525360473a778f91021e3be58fd4bfd72ee5 "makefs: correct El Torito bood record" was not reported by me. (Also it has typo "bood" in the title.) I posted PR 203531 after regression tests with xorriso where repacking of the then current FreeBSD ISO showed more than the expected problems. The surplus bytes in the Boot Record were not recognized by those tests. Have a nice day :) Thomas
Hi, Ed Maste wrote: > We could get away with omitting the NM for files that can't be > misrepresented I believe (e.g. a file named 1234.567), but I'm not > sure it's worth the effort. About all operating systems make beautifications to the dull ISO 9660 names when they get displayed. E.g. Linux offers three ways in man mount: "normal", "off", "acorn". I have no ISOs with "Acorn extensions". But i can switch between the the display of name "1234.567" and "1234.567;1". (The latter with: mount -o norock,nojoliet,map=off ) So i'd say that leaving out the NM for "1234.567" is an invitation for a new PR from some puzzled user who curiously inspects the ISO's content. Have a nice day :) Thomas
I did indeed include the wrong PR in the El Torito boot record commit. However, you're also the reporter of PR203646? > But i > can switch between the the display of name "1234.567" and "1234.567;1". > (The latter with: mount -o norock,nojoliet,map=off ) but with "norock" wouldn't the Linux kernel just ignore NM records altogether?
Hi, Ed Maste wrote: > I did indeed include the wrong PR in the El Torito boot record commit. > However, you're also the reporter of PR203646? You are right. That one stems from inspecting Coverity reports, not from my regression tests. (I cannot even remember why i looked into those reports, 7.5 years ago.) Can i find out what PRs of mine are pending ? Searching for "scdbackup" yields no match. I wrote: > > i can switch between the the display of name "1234.567" and "1234.567;1". > > (The latter with: mount -o norock,nojoliet,map=off ) > but with "norock" wouldn't the Linux kernel just ignore NM records > altogether? Yes. I was too lazy to fake an ISO where not all files have NM records. It's time to try what happens. First i make a small ISO with Rock Ridge (the "rr" in "xorriso"): touch x xx xorriso -compliance no_emul_toc -padding 0 -outdev test.iso \ -map x /1234.567 -map xx /7654.321 A hex dumper shows me that the NM entry of /1234.567 begins at byte 37198 decimal. So i deface it by: echo -n XY | dd of=test.iso conv=notrunc bs=1 seek=37198 count=2 (All Rock Ridge readers are supposed to ignore SUSP entries which they don't know. "XY" is not defined by anybody, as far as i know.) Next i mount it on Linux with Rock Ridge enabled and ISO 9660 name mapping off mount -o map=off test.iso /mnt/iso and list the content $ ls -1 /mnt/iso 1234.567;1 7654.321 The second file's directory entry still has its NM and thus ls reports the name without ";". It looks better without map=off: $ ls -1 /mnt/iso 1234.567 7654.321 But that's the operating system specific beautification of "1234.567;1". Have a nice day :) Thomas
(In reply to scdbackup from comment #14) > Can i find out what PRs of mine are pending ? > Searching for "scdbackup" yields no match. Yeah, Bugzilla's search isn't intuitive. You can click on the search link (not the search button) and then there are options to search by submitter / assignee / etc. I see the following PRs of yours still open: 203944 203943 203940 203938 203937 203646 203531 > Yes. I was too lazy to fake an ISO where not all files have NM records. > It's time to try what happens. Thanks for investigating! So the simplest approach is the correct one.
For problem 4: https://reviews.freebsd.org/D39258 I think we could still omit NM for directories that won't change with mapping (e.g. 1234.567) with no ill effect, but think it's not worth the trouble.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=978013a0945d4c6b7ab3ee798dc13c74e913762a commit 978013a0945d4c6b7ab3ee798dc13c74e913762a Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-03-24 17:53:59 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-03-25 13:25:18 +0000 makefs: emit NM records for all directory entries We previously attempted to emit Rock Ridge NM records only when the name represented by the Rock Ridge extensions would actually differ. We would omit the record for an all-upper-case directory name, however Linux (and perhaps other operating systems) map names with no NM record to lowercase. This affected only directories, as file names have an implicit ";1" version number appended and thus always differ. To solve, just emit NM records for all entries other than DOT and DOTDOT . We could continue to omit the NM record for directories that would avoid mapping (for example, one named 1234.567) but this does not seem worth the complexity. PR: 203531 Reported by: Thomas Schmitt <scdbackup@gmx.net Reviewed by: kevans Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39258 usr.sbin/makefs/cd9660/iso9660_rrip.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-)
For problem 1: https://reviews.freebsd.org/D39455
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7bc4ccf3aea935dde8ffc3e7c287884e22f87646 commit 7bc4ccf3aea935dde8ffc3e7c287884e22f87646 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-04-06 16:53:00 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-04-06 17:47:35 +0000 makefs: avoid uninitialized memory in root directory date Move date setting into cd9660_populate_iso_dir_record so there is no path that leaves it unset. PR: 203531 Reported by: Thomas Schmitt <scdbackup@gmx.net> Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39258 usr.sbin/makefs/cd9660.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3a52cc4445ba3e5cbee7b802822be6a1e122ad13 commit 3a52cc4445ba3e5cbee7b802822be6a1e122ad13 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-03-24 17:53:59 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-04-10 13:37:40 +0000 makefs: emit NM records for all directory entries We previously attempted to emit Rock Ridge NM records only when the name represented by the Rock Ridge extensions would actually differ. We would omit the record for an all-upper-case directory name, however Linux (and perhaps other operating systems) map names with no NM record to lowercase. This affected only directories, as file names have an implicit ";1" version number appended and thus always differ. To solve, just emit NM records for all entries other than DOT and DOTDOT . We could continue to omit the NM record for directories that would avoid mapping (for example, one named 1234.567) but this does not seem worth the complexity. PR: 203531 Reported by: Thomas Schmitt <scdbackup@gmx.net Reviewed by: kevans Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39258 (cherry picked from commit 978013a0945d4c6b7ab3ee798dc13c74e913762a) usr.sbin/makefs/cd9660/iso9660_rrip.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=62f8e141920c555f4a80038062ba8d0edc3b79c5 commit 62f8e141920c555f4a80038062ba8d0edc3b79c5 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-03-23 12:35:34 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-04-10 13:37:40 +0000 makefs: correct iso9660 Rock Ridge NM values These are not actually used by makefs (yet), but ought to match the spec. See RRIP 4.1.4 Description of the "NM" System Use Entry for details. PR: 203531 Sponsored by: The FreeBSD Foundation (cherry picked from commit c3ec19359e05c3b609e461896aa6ab4d6ad8121f) usr.sbin/makefs/cd9660/iso9660_rrip.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b95746135307c8146e342e55928bc27e1521f035 commit b95746135307c8146e342e55928bc27e1521f035 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-03-23 17:02:44 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-04-10 13:37:40 +0000 makefs: correct El Torito bood record The boot catalog pointer is a DWord, but we previously populated it via cd9660_bothendian_dword which overwrote four unused bytes following it. See El Torito 1.0 (1995) Figure 7 for details. PR: 203531, 203646 Reported by: Coverity Scan Reported by: Thomas Schmitt <scdbackup@gmx.net> Reviewed by: kevans CID: 977470 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39231 (cherry picked from commit 9f2a525360473a778f91021e3be58fd4bfd72ee5) usr.sbin/makefs/cd9660/cd9660_eltorito.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a79601b07a9ffacd4a69195f4a175c228d96ac06 commit a79601b07a9ffacd4a69195f4a175c228d96ac06 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-03-22 23:42:45 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-04-10 13:37:40 +0000 makefs: correct iso9660 Rock Ridge TF timestamps The bit definitions for the TF_* timestamp bits (TF_MODIFY, etc.) were incorrect, and timestamps were written in the wrong order. See RRIP 4.1.6 Description of the "TF" System Use Entry for details. PR: 203531 Reported by: Thomas Schmitt <scdbackup@gmx.net> Reviewed by: jrtc27, kevans Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39221 (cherry picked from commit c65c969bd5d4ae7c52dedafb3c39b7e933079d4a) usr.sbin/makefs/cd9660/iso9660_rrip.c | 4 ++-- usr.sbin/makefs/cd9660/iso9660_rrip.h | 16 ++++++++-------- 2 files changed, 10 insertions(+), 10 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1a38a53924e5b43a14bea8e87aac42176c336ff8 commit 1a38a53924e5b43a14bea8e87aac42176c336ff8 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-04-06 16:53:00 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-04-14 12:10:37 +0000 makefs: avoid uninitialized memory in root directory date Move date setting into cd9660_populate_iso_dir_record so there is no path that leaves it unset. PR: 203531 Reported by: Thomas Schmitt <scdbackup@gmx.net> Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39258 (cherry picked from commit 7bc4ccf3aea935dde8ffc3e7c287884e22f87646) usr.sbin/makefs/cd9660.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-)
For problem 2: https://reviews.freebsd.org/D39662 (not yet tested at time of review creation)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=dd9059b3e9a1711d54c1d511a2cbb23e6e23f556 commit dd9059b3e9a1711d54c1d511a2cbb23e6e23f556 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-04-18 13:57:29 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-04-20 16:20:56 +0000 makefs: set cd9660 Rock Ridge timestamps for . and .. DOT and DOTDOT entries have special handling, and previously only Rock Ridge PX (POSIX attributes) entries were attached. Add TF (timestamp) entries as well. PR: 203531 Reported by: Thomas Schmitt <scdbackup@gmx.net> Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39662 usr.sbin/makefs/cd9660/iso9660_rrip.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Thank you, (In reply to commit-hook from comment #26) MFC for this most recent commit?
(In reply to Graham Perrin from comment #27) Yep, I will sync makefs updates (at least cd9660) to stable/13 before too long.
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0001406ae235412745951ecf5832c688ee6079da commit 0001406ae235412745951ecf5832c688ee6079da Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-04-18 13:57:29 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-04-27 16:45:37 +0000 makefs: set cd9660 Rock Ridge timestamps for . and .. DOT and DOTDOT entries have special handling, and previously only Rock Ridge PX (POSIX attributes) entries were attached. Add TF (timestamp) entries as well. PR: 203531 Reported by: Thomas Schmitt <scdbackup@gmx.net> Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39662 (cherry picked from commit dd9059b3e9a1711d54c1d511a2cbb23e6e23f556) usr.sbin/makefs/cd9660/iso9660_rrip.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Hi, thanks for having taken care of this report. It was a joy to watch the progress. Have a nice day :) Thomas
(In reply to scdbackup from comment #30) Thank you for your very detailed reports. I apologize for the amount of time it took to resolve these.