Re: [Libcdio-devel] Joliet translated names

[Chris Lalancette]

Hi,
     Ah, OK.  Yes, I thought about using something like that on it; I
was wondering if there was anything built into the library to do that,
but I guess not.  Thanks for the detailed response.

By the way, I do like glib, as well; I have used it for a few of my
other projects, and I am always grateful for the primitives it offers.

Thanks,
Chris Lalancette

On 3/17/06, R. Bernstein <address@hidden> wrote:
> I just looked at the problem you reported in more detail and thought
> about it some more. I think the most fool-proof and simplest solution
> would to change vfs_smbcdio.c to record the translation such as by
> using a hash table.
>
> In more detail, inside procedure smbcdio_stat() in the loop that
> processes iso9660_ifs_readdir, a hash table can map the translated
> name back into the original ISO 9660 name reported. It would also
> catch a problems when several names translate to the same string.  I
> believe this happen and it should probably be handled. For example, if
> there is foo.txt;1 and foo.txt;2 - do you want both files to be listed
> or the latest revision (which I think is foo.txt;2).
>
> Here's some skeleton code for changing vfs_smbcdio.c to use a glib hash table 
> to accomplish
> the above:
>
>    ...
>    #include <glib-2.0/glib.h>
>     ...
>    GHashTable *iso_files = g_hash_table_new(g_str_hash, g_str_equal);
>    ...
>    if (g_hash_table_lookup(iso_files, translated_name)) {
>       /* Do whatever you want to do on duplicate filenames. This might 
> happen. */
>       ...
>    } else {
>       /* insert the new value */
>       g_hash_table_insert(iso_files, g_strdup(translated_name), 
> g_strdup(iso_name));
>    }
>    ...
>
> And then in smbcdio_open():
>
>   char *iso_filename = g_hash_table_lookup(iso_files, filename);
>   if (iso_filename) {
>     cdiostat = iso9660_ifs_stat(p_iso, iso_filename);
>     ...
>
> For information on using glib2, see
> http://developer.gnome.org/doc/API/glib/ or
> http://www-128.ibm.com/developerworks/linux/library/l-glib2.html
>
>
> If you want me to try to modify the vfs_smbcdio.c code using the above
> approach let me know.  Going this route, would require folks to have
> glib installed which I don't think is a bad idea -- I have a dream
> that libcdio would one day use it as well.
>
> Chris Lalancette writes:
>  > All,
>  >     I have a question about using the libcdio library, that I just
>  > can't seem to figure out by looking at the documentation/examples.
>  > Let me lay out the situation:
>  >
>  > I am updating a Samba VFS module to use libcdio to access CD devices
>  > without mounting them.  What the Samba VFS module does is provide all
>  > of the "filesystem" system calls; i.e. opendir, readdir, closedir,
>  > open, read, write, close, stat, etc. (obviously for CDROM only the
>  > read ones work).  So far I have it so that when opendir is called, I
>  > use libcdio to find the directory in question, and build up a linked
>  > list of entries.  When a readdir is called, I then "pop" one of those
>  > entries off.  This works all well and good, as long as I do not use
>  > "translated" names.  That is, if I build the linked list with ISO9660
>  > (not Joliet) names, when a readdir happens, I return a name like
>  > "foo.txt;1", and then that name gets passed back in to a stat(), or
>  > open(), or whatever, and works fine.  If I use the name returned from
>  > "iso9660_name_translate_ext()", then the stat() or open() cannot find
>  > the name.  Basically I think I need an "untranslate", but I'm not
>  > quite sure how to go about that.  Is there something obvious I am
>  > missing here, or that I am going about in the wrong way?  If you want
>  > to see an older version of the code (which exhibits the same
>  > problems), please look at
>  > http://www.ontologistics.net/OpenSource/Samba/index.php
>  >
>  > Thanks for your help,
>  > Chris Lalancette
>  >
>  >
>  > _______________________________________________
>  > Libcdio-devel mailing list
>  > address@hidden
>  > http://lists.gnu.org/mailman/listinfo/libcdio-devel
>  >
>