#162 Check 'iTunes_Control' before 'iPod_Control' (iPhone/Touch)

closed-fixed
Jorg Schuler
libgpod (41)
5
2009-11-22
2009-01-26
Paul Sladen
No

With Release XYZ of iTunes and the release of the iPhone/iTouch, Apple rev'ed their database format from version 2 to version 4.

At the same time the filesystem layout changed, with the iTunes-produced hierarchy base directory being renamed from:

iPod_Control/

to:

iTunes_Control/

Please change the code to also search for this second directory, so that iPhone/iPod Touch users don't have to symlink these together.

The current symlink "solution" to link the two names together is a hack, and, as the AFC protocol does not full support symlinks (create, delete: yes; but readlink/rename: no) is not a solution.

This is now an issue as the other two parts of the puzzle for full support of these recent devices is getting to the point of near "0.1-ish" completeness.

-Paul Sladen

Discussion

  • Paul Sladen
    Paul Sladen
    2009-01-26

    Adjust summary

     
  • Paul Sladen
    Paul Sladen
    2009-01-26

    • summary: Check 'iTunes_Control' aswell as 'iPod_Control' iPhone/iTouc --> Check 'iTunes_Control' aswell as 'iPod_Control' iPhone/Touch
     
  • Jorg Schuler
    Jorg Schuler
    2009-01-31

    • assigned_to: nobody --> jcsjcs
     
  • Jorg Schuler
    Jorg Schuler
    2009-01-31

    Thanks for writing.

    As far as I can tell, we are already checking for iTunes_Control. This check, however, fails if you create a symlink. Symlink is bad.

    Which version of libgpod are you using?

    JCS.

     
  • David Kohen
    David Kohen
    2009-04-02

    • labels: --> libgpod
     
  • jcs: just had another report of somebody complaining about this on the 'libiphone-devel' list. It should be possible to fix the issue by checker for the newest name first and then failing back to the older name (so try to open 'iTunes_Control' first and then if that doesn't exist, try to open 'iPod_Control').

    If that's unreasonable the other options is probably to just dive in and open 'iPod_Control/iTunesDB' without trying to make any "clever" checks first. This should open across the symlink, even if readlink() itself is not implemented over the protocol.

     
  • Paul Sladen
    Paul Sladen
    2009-04-04

    • summary: Check 'iTunes_Control' aswell as 'iPod_Control' iPhone/Touch --> Check 'iTunes_Control' before 'iPod_Control' (iPhone/Touch)
     
  • Paul Sladen
    Paul Sladen
    2009-04-04

    Previous comment by -sladen. Adjust summary to be more explicit.

     
  • As Jorg said, we already check for iTunes_Control and nothing else. libgpod might get confused if you put a symlink, but I'm not sure why you'd do that. I think there are some bugs in the way we handle iTunes_Control/iPod_Control, but this needs investigating instead of blindly applying a workaround.

     
  • This should be fixed, I wasted my time because of these softlinks being present in there.
    They are added by ipod-convenience if I remember right.

     
  • ipod-convenience shouldn't be used then ;)

     
    • status: open --> closed-fixed