[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pete Batard
Subject: [Libcdio-devel] [PATCH] Update the extract.c sample
Date: Wed, 30 Oct 2013 20:10:20 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0


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:


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.


>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) + 
     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 
     if ( (strcmp(p_statbuf->filename, ".") == 0)
       || (strcmp(p_statbuf->filename, "..") == 0) )
-    iso9660_name_translate_ext(p_statbuf->filename, psz_basename, 
+    /* 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, 
+    }
     if (p_statbuf->type == _STAT_DIR) {
       if (iso_extract_files(p_iso, psz_iso_name))

reply via email to

[Prev in Thread] Current Thread [Next in Thread]