Ah, I'm going to eat my own words, because apparently case-insensitive
access works in one of my systems, and not in the other. I developed
this program in the one where it doesn't work, hence my using of
On Thu, Apr 8, 2010 at 13:56, Adeodato Simó <dato@...> wrote:
> Hello Christophe. Thanks for looking at the patch and for your reply.
> After a closer look, it seems that I don't really need itdb_resolve_path()
> after all...
> While writing my code, I noticed that the "ipod_path" member of a track
> object had components in a different case that on the filesystem. This
> led me to believe that I needed itdb_resolve_path(), since its main
> purpose is to resolve a path case-insensitively (this is why it calls
> into the filesystem with stat & readdir, which makes it slower).
> What I didn't realize is that Linux's vfat implementation already allows
> case-insensitive access by itself, hence itdb_resolve_path() is not
> needed. I realized this while taking a look at your itdb_device_resolve_path()
> function, which doesn't call into the filesystem at all, and made me wonder.
> So, uhm, I think I'm fine, and I don't think itdb_device_resolve_path()
> would be needed from Python either because it's just equivalent to
> os.path.join. In fact I don't understand why itdb_device_resolve_path()
> is needed at all after your 529f571, since it seems to be strictly
> equivalent to g_build_filename().
> I can only think the old itdb_resolve_path() could be useful for
> somebody whose kernel (?) doesn't allow case-insensitive access for
> vfat; and if they use Python, my patch could be useful to them. Other
> than that, it seems Python users should use os.path.join, and C users
> Does this explanation make sense to you?
> By the way when you say itdb_resolve_path() is deprecated, I assume you
> mean it's deprecated as an equivalent of g_build_filename(), but that it
> won't be removed from the library if 0.8.0 is to be compatible with 0.7.x
> (which the release notes seem to imply). Hence this should not be a
> concern with respect to applying the patch.
> Anyway, ciao!
>> 2010/4/8 Adeodato Simó <dato@...>:
>>> The patch is pretty straightforward and it allows to use itdb_resolve_path()
>>> from python, like this:
>>> I hope you will integrate it, though I guess it'll only be released as
>>> part of 0.8.0. In any case, if you have any comments, doubts or suggestions
>>> please let me know!
>> itdb_resolve_path will probably be deprecated in libgpod 0.8.0 in
>> favour of a new itdb_device_resolve_path (Itdb_Device *device, char
>> *component, ...);
>> This is because stat() is really slow with iPhones/iPod Touch and
>> itdb_resolve_path makes a ton of it. The work that has been done
>> toward that so far can be seen at
>> I suspect an itdb_device_resolve_pathv functions might be needed to be
>> easily bindable?
>> So I'm not sure it worth having this patch at this point, I'd like to
>> land the branch above for 0.7.94. And I'll gladly take a patch to wrap
>> itdb_device_resolve_path :)
>> Out of curiosity, why did you need this function?
>> Thanks for the patch,
> - Are you sure we're good?
> - Always.
> -- Rory and Lorelai
- Are you sure we're good?
-- Rory and Lorelai