Regression between `20220201T112553` and `20220301T213949`.

[maxz]

Version I first encountered this regression in the current version 20220501T221948 and then determined that it was not present in version 20220201T112553 and first appeared in version 20220301T213949.

Describe the bug The dumping of certain DVDs aborts while reading the directory record. I have dumped those discs successfully with older versions of DIC and was just redumping them with the latest version. I can still dump them successfully with version 20220201T112553, but not with any later version.

Disc title X2: The Threat and X3: Reunion (both for Linux) display this problem.

Disc ringcode

Outer mastering code: X2DVDROMVLIN01    79.0    mediamfg.com    30011101-74460
Outer mastering SID: IFPI LN16
Mould SID (data side): IFPI JN22

Log file X2 (20220201T112553).zip X2 (20220301T213949).zip X2 (20220501T221948).zip

[maxz]

Additionally I should mention that the dump using the old DIC version produces a correct ISO image, which matches dumps with dd.

The error is probably related to commit c7076d164a825d8402dd0a5e0778ba2070ec0348 or commit ed47a52b57bf2272d2f957694a3aa8a44076352c.

[maxz]

It also happens with Cold War, Sacred: Gold, Shadowgrounds and Shadowgrounds Survivor. Basically with all Linux exclusive DVDs.

[saramibreak]

The error is probably related to commit

Yes, then, I have a question.

              Length of Directory Record: 140
        Extended Attribute Record Length: 0
                      Location of Extent: 741787
                             Data Length: 0
                 Recording Date and Time: 2005-12-30T22:56:32+00:00
                              File Flags: 0 (Visible, File, No Associated, No Record Format, No Owner/Group ID, Final Directory Record)
                          File Unit Size: 0
                     Interleave Gap Size: 0
                  Volume Sequence Number: 1
               Length of File Identifier: 11
                         File Identifier: DRAGONFL.;1
FullPath: /LGP_UPDA/BIN/DRAGONFL.

Filesize (Data Length) of the "DRAGONFL." is 0. What is this file? Is this normal for linux system?

[maxz]

A file with data length of 0 is nothing special on Linux. Many programs use such files to mark something, basically using it like a lock. There are all kind of special files, which are not traditional files like links, device files and so on.

In this particular case, DragonflyBSD (displayed as DRAGONFL. in the log) is a symbolic link to the Linux directory and symbolic links are a very, very common occurrence and used a lot on all unixoid systems. They do not contain any data but only contain an inode entry which point to another file-like object. In the same directory there are 3 other symbolic links to Linux.

Actually symbolic links also exist in Windows and did so for many years now (see mklink and junction commands). But since they are rather uncommon to use on Windows, it would probably be very, very rare to find one on a disc.

[maxz]

I am not sure how familiar you are with inodes. In this case the listed size of 2048 is just the standard size of an inode and not the real file size or content, so only the size of the file-system-metadata structure.

stat of the link:

  File: DragonflyBSD/
  Size: 2048            Blocks: 4          IO Block: 2048   directory
Device: 700h/1792d      Inode: 5696        Links: 6
Access: (0755/drwxr-xr-x)  Uid: (  500/ UNKNOWN)   Gid: (  500/ UNKNOWN)
Access: 2006-04-27 15:44:43.000000000 +0200
Modify: 2005-12-30 23:56:32.000000000 +0100
Change: 2006-04-08 08:19:47.000000000 +0200
 Birth: -

ls -l of lgp_update/bin/:

lrwxrwxrwx 1 500 500    5 Apr  8  2006 DragonflyBSD -> Linux
lrwxrwxrwx 1 500 500    5 Apr  8  2006 FreeBSD -> Linux
drwxr-xr-x 6 500 500 2048 Dec 30  2005 Linux
lrwxrwxrwx 1 500 500    5 Apr  8  2006 NetBSD -> Linux
lrwxrwxrwx 1 500 500    5 Apr  8  2006 OpenBSD -> Linux

Maybe std::filesystem::is_symlink could help you. But there are probably various reasons to have other zero-length files on a disc, even if they are not a symlink. Maybe virtually all cases could be covered by std::filesystem::is_regular_file, but then again, an empty regular file can also be valid depending on how it is used.

[saramibreak]

DiscImageCreator_linux_test.tar.gz

• fixed: allow "Data Length 0"

[maxz]

It works fine. Thank you. I hope it soon makes it into a proper new release.

sha1sum of the ISO created with ddrescue: 7b96c7870b0fec2bdbb808d8d512ca00c143eda5 X2.iso

And the checksums of the dump with version 20220605T102919: <rom name="CDROM.iso" size="1542356992" crc="c5f7fe85" md5="32c67ee168680bf47ddc6a2c43474300" sha1="7b96c7870b0fec2bdbb808d8d512ca00c143eda5"/>

The logs of the dump with your test version for reference: X2 (20220605T102919).zip