Retrouver un fichier
orfait
Membre
Bonjour,
Je viens chercher de l'aide par ici car je suis confronté à un problème depuis plusieurs jours... il s'agit de retrouver un fichier.
Plutôt que d'essayer d'expliquer de façon abstraite, je vais faire un exemple.
Mon application doit se charger de gérer une collection de mp3. Alors imaginons, l'utilisateur a scanné son répertoire de mp3 pour avoir diverses informations directement dans un fichier au format xml (titre, auteur, genre et BPM). Dans ce fichier se trouve aussi le chemin du fichier mp3. Jusque là , rien de bien complexe. Mais là où ça se complique, c'est que si l'utilisateur déplace un fichier (application fermée), il faut retrouver ce fichier de façon transparente, sans ramer et sans tout rescanner (ou alors, rescanner très très vite sans tout faire ramer).
Pire : l'utilisateur déplace le fichier, le renomme et change l'ID3 tag.
J'ai vu une fonction identique sur un soft de DJ sur un PC. Alors outre le fait que je suis persuadé que c'est possible, je me demande comment...
Alors si quelqu'un a une idée, ou tout simplement une piste, je suis preneur... et il n'y a pas d'idée idiote !
Merci à ceux qui se pencheront sur mon problème.
Je viens chercher de l'aide par ici car je suis confronté à un problème depuis plusieurs jours... il s'agit de retrouver un fichier.
Plutôt que d'essayer d'expliquer de façon abstraite, je vais faire un exemple.
Mon application doit se charger de gérer une collection de mp3. Alors imaginons, l'utilisateur a scanné son répertoire de mp3 pour avoir diverses informations directement dans un fichier au format xml (titre, auteur, genre et BPM). Dans ce fichier se trouve aussi le chemin du fichier mp3. Jusque là , rien de bien complexe. Mais là où ça se complique, c'est que si l'utilisateur déplace un fichier (application fermée), il faut retrouver ce fichier de façon transparente, sans ramer et sans tout rescanner (ou alors, rescanner très très vite sans tout faire ramer).
Pire : l'utilisateur déplace le fichier, le renomme et change l'ID3 tag.
J'ai vu une fonction identique sur un soft de DJ sur un PC. Alors outre le fait que je suis persuadé que c'est possible, je me demande comment...
Alors si quelqu'un a une idée, ou tout simplement une piste, je suis preneur... et il n'y a pas d'idée idiote !
Merci à ceux qui se pencheront sur mon problème.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
SI c'est impossible, je ferais une solution à base de spotlight... c'est une bonne idée 8--)
En fait, il n'existerait pas un identificateur unique pour chaque fichier ?
Si, les inodes dans une certaine mesure...
Mais sur les systèmes UNIX, c'est impossible de retrouver un chemin à partir de l'inode (particulièrement à cause des hardlinks)
Il existe cependant une fonction qui donne le dernier stocké dans la cache du système (me souviens plus son nom...)
Si tu as la maitrise sur la bd xml, alors, ajoute un champ contenant le chemin en dur, et ajoute un champ de type data/blob contenant les données de l'alias. Ce dernier champ sera utilisé seulement sous environnement Mac.
Alors j'ai oublié un détail qui a sont importance :les fichiers peuvent être renommés/déplacés sur un autre système. Et aussi, supprimés puis recopiés à nouveau. Même si c'est le même fichier, ça coince aussi à ce niveau.
Donc finalement, je crois que je vais devoir rescanner à chaque fois.
Car l'autre détail qui est aussi important, c'est que dodoze ne veut pas de HFS tout comme OSX ne veut pas écrire sur du NTFS, donc la synchronisation est faite sur un poste avec MacDrive ou bien sur OSX (juste dans le sens disque NTFS vers HFS).
Donc je crois que ca va tourner sur les dates de modification des répartoires et des inodes (ou MD5) des fichiers.
Je pense qu'on peut stopper le topic à ce niveau (sauf idée géniale) puisque à partir de là , c'est de la patience qu'il me faut (surtout que c'est pas moi qui fait le dev sur windows).
Encore merci pour les réponses !
Sinon les pistes des inodes ou des aliases est à mon avis le plus adéquat.
OK ça alourdi... Alors pourquoi ne faire 2 XMLs ? Un qui serait un XML qui contient les covers et/ou autres infos lourde que tu enregistres sous une extension genre .library. Le XML léger contiendrait les tracks + l'index où retrouver les covers sur l'autre fichier.
Là tu me dis "OK, mais si ils le supprime ?" Et ben tant pis pour eux ! Si je supprime le fichier iTunes Library je perds tout.. tu peux tester en le déplaçant simplement ailleurs, et ensuite tu lances iTunes. Résultat : Biblio complètement vide.
Je pense qu'il faut allez chercher trop loin et prendre au plus simple.
Tu as peut-être un côté négatif dans cette solution (mais dans ce cas, iTunes en a un gros aussi). Mais d'un autre côté c'est pas mal car :
- On peut pas faire plus simple
- L'utilisateur a pas forcément envie de stocker ses images dans un dossier. Personnellement je suis content que iTunes me stocke ça je ne sais où et que j'en entende plus parler. Il gère comme un grand. Je peux supprimer l'image originale sans problème.
Après la solution des alias, c'est bien. Ptete plus compliqué, mais bien. Sauf que, si l'utilisateur supprime l'image de son disque dur ?
Edit : Boulet inside ;D
Ce que je cherche à faire, c'est une sorte de synchronisation entre deux lieux de stockage, mais avec prise en charge du fait qu'un fichier ai pu être renommé/déplacé/modifié.
Il n'y a pas d'image associée à un mp3 ???
Euh... dans les tags ID3v2, là où il faut
Mais pourquoi parles-tu des images ? Je ne vois pas le rapport avec le sujet...
en fait j'ai lu "BMP" à la place de "BPM" et j'ai tilté (je ne sais pas pourquoi) sur les images.... :(renaud):
Boulet inside ;D ;D ;D
Au moins ça me fait rire la veille des résultats du bac
Et pis ça doit être à cause du fait que je touche beaucoup à iTunes et aux covers en ce moment. Franchement désolé si à chaque fois que je poste je dis de la merde ;D
C'est ce que j'avais supposé
Donc je vais très très probablement utiliser ça, malgré la taille (640 bits).
Je viens d'envoyer la balle dans le camp du programmeur sous windows, j'attends de connaitre sa solution pour son système. Après, on verra comment synchroniser... ce sera probablement une véritable usine à gaz...
ça m'étonne beaucoup ça... ???
J'ajouterais un drapeaux sur chaque entrées dans le xml avec pour valeur 0
Au chargement du xml je lancerais un thread charger de vérifier la validité de chaque chemin et je passerais le drapeau à 1
Lors d'un accès a une entrée si le drapeau est à 1 je ferais confiance au chemin sinon je recherche le fichier
Et enfin lors de la sauvegarde du xml, je ferais un clone avec tous les drapeaux à 0
NseaProtector : j'avais ce genre d'idée mais comme je ne stocke plus de chemin, il suffit de vérifier les FSRef au fur et à mesure.
Bref, j'attends toujours la solution côté windows...
En revanche, ce qui ne change pas, c'est le inode.
Si tes fichiers n'ont qu'une référence à chaque fois, je peux essayer de te retrouver la fonction capable de retrouver le path à partir de l'inode...
Si tu trouves ça, c'est fabuleux !
Sinon, je vais regarder encore 2 choses :
- attributesOfItemAtPath
- NDAlias ( http://homepage.mac.com/nathan_day/pages/source.xml )
EDIT1 : Avec ceci :
J'obtiens le inode sans problème.
EDIT2, le dernier :
Avec NDAlias, je stocke les données dans un NSData écris dans un fichier xml, le fichier est toujours retrouvé, même après démontage et remontage du disque. Le changement de disque n'est pas géré (comme pour un alias classique). Et le déplacement d'un fichier sur windows n'est pas géré non plus.
On obtient les deux avec lstat.
J'ai une fonction capable de donner le path à partir d'un file descriptor :
Ou à partir d'un "vnode_t"
Mais je n'arrive pas à trouver comment créer un vnode_t ou un file descriptor à partir du ino_t et du dev_t...