[Libcdio-devel] [PATCH] Update the extract.c sample

[Pete Batard]

Hi,

For the sake of completion, I'm forwarding are some of the changes I 
applied to the equivalent of extract.c I use in my app, and that should 
also probably be included in libcdio.

The Rock Ridge exception is something that other samples, such as 
cd-info.c, already do. Without this extracted files from RR ISOs will be 
incorrect.


Now, the check for empty filenames returned by udf_get_filename() is 
more of a workaround that anything else, and probably something in need 
of a better fix... though I can't say for sure what the real issue is at 
this stage.

The problem is that, on some UDF images such as the unofficial "Windows 
8 + Server 2012 AIO 19 in 1", udf_readdir() return entries that aren't 
seen as directories (udf_is_dir(p_udf_dirent) is false) and yet don't 
seem to be regular files either, as the filename (returned by 
udf_get_filename(p_udf_dirent)) is the empty string and if you try to 
save the data from such a "file", all you get is internal UDF data.

For instance, the UDF mentioned above has the following set of files and 
directories at the root level:

boot/
efi/
sources/
support/
autorun.inf
bootmgr
bootmgr.efi
setup.exe

When processed by libcdio/udf_readdir() however, besides the files 
listed above, you will get an extra nameless file (see attached) that 
clearly looks like UDF internal content. Such a file also isn't listed 
by other tools, such as 7-zip on Windows for instance. Also, ignoring 
this extra file altogether doesn't seem to impact libcdio in the 
slightest in terms of parsing the expected directory entries and finding 
subdirectories content.

Of course, since this is a non official UDF image, I have no idea how it 
was generated, and whether this has anything to do with libcdio, though 
my guess is that we probably want libcdio to ignore these nameless 
entries somehow.

Other point worth noting is that when I extracted the content from the 
image, and recreated it using ImgBurn, the issue disappeared with the 
new image. So there's definitely something with regards to how the image 
was created. I tried to play 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 <address@hidden>
Date: Wed, 30 Oct 2013 18:25:31 +0000
Subject: [PATCH] Update extract sample

---
 example/extract.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/example/extract.c b/example/extract.c
index 0e5606f..2641f72 100644
--- a/example/extract.c
+++ b/example/extract.c
@@ -101,6 +101,8 @@ static int udf_extract_files(udf_t *p_udf, udf_dirent_t 
*p_udf_dirent, const cha
 
   while (udf_readdir(p_udf_dirent)) {
     psz_basename = udf_get_filename(p_udf_dirent);
+    if (strlen(psz_basename) == 0)
+      continue;
     i_length = 3 + strlen(psz_path) + strlen(psz_basename) + 
strlen(psz_extract_dir);
     psz_fullpath = (char*)calloc(sizeof(char), i_length);
     if (psz_fullpath == NULL) {
@@ -189,7 +191,12 @@ static int iso_extract_files(iso9660_t* p_iso, const char 
*psz_path)
     if ( (strcmp(p_statbuf->filename, ".") == 0)
       || (strcmp(p_statbuf->filename, "..") == 0) )
       continue;
-    iso9660_name_translate_ext(p_statbuf->filename, psz_basename, 
i_joliet_level);
+    /* Rock Ridge requires an exception */
+    if (p_statbuf->rr.b3_rock == yep) {
+      strcpy(psz_basename, p_statbuf->filename);
+    } else {
+      iso9660_name_translate_ext(p_statbuf->filename, psz_basename, 
i_joliet_level);
+    }
     if (p_statbuf->type == _STAT_DIR) {
       _mkdir(psz_fullpath);
       if (iso_extract_files(p_iso, psz_iso_name))
-- 
1.8.0.msysgit.0