[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 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Libcdio-devel] [PATCH] Update the extract.c sample,
Pete Batard <=