›

Identification d'un document : comment faire en cas de duplication

colas_colas_ Membre
dans API AppKit #1

Bonjour à  tous !


 


Je gère une application qui est document-based. J'ai un système qui assigne un id unique à  chaque document lors de sa création. (Cet id me permet ensuite de créer un dossier dédié dans le dossier AppSupport pour écrire diverses données, dont des sauvegardes)


 


Mon système marche très bien mais souffre d'une faille : lorsqu'un utilisateur duplique un document (dans le finder), le nouveau document hérite du même id. Je souhaitais avoir votre avis sur comment faire. Ma première idée serait de contrôler la date de création du document à  l'ouverture du document. Si elle diffère de ce qui est enregistré, je créerai un nouvel id et dupliquerai le dossier du AppSupport.


 


Qu'en pensez-vous ? Encore des failles ? Une meilleure solution ?


 


Merci !


 


Colas


Réponses

  • AliGatorAliGator Membre, Modérateur
    #2
    Regarde dans la doc de NSURL ce qui concerne les BookmarkData.

    Dans l'introduction de la Class Reference de NSURL, ils expliquent le principe des BookmarkURLs. Ce sont des sortes d'URLs persistantes même si tu changes l'emplacement du fichier. Je suppose qu'ils doivent certainement faire un truc comme se baser sur le nodeID UNIX du fichier pour identifier chaque fichier de façon unique, même s'il change de place.

    J'ai jamais encore utilisé les bookmarkData mais je pense que ça vaut le coup d'essayer de creuser et voir comment ça marche. Faut juste confirmer avec quelques tests que le bookmarkData se comporte bien comme je le comprends, c'est à  dire ne change pas à  chaque fois que tu modifies et sauves ton document, ne change pas si tu déplaces le fichier, et si tu fais une copie du document la copie ait un bookmarkData différent de l'original. Et si tu confirmes ça, tu pourras l'utiliser comme identifiant unique de ton doc par exemple.


    PS : Pourquoi avoir besoin de sauvegarder des backups de ton document toi-même par ton app ? Je veux dire pourquoi tu n'utilises pas Auto-Save & Versions, le truc intégré à  OSX Lion ?
  • colas_colas_ Membre
    #3

    Merci AliGator pour ta réponse, je vais regarder ça.


     


    Pour le autosave, je ne l'ai pas choisi (je ne sais plus trop pourquoi ;-) ). Je pense que la structure d'un document est trop complexe (je mélange coredata et additionalData (dans un file package). Et puis, j'aime bien savoir ce que je fais. Je sauvegarde pas uniquement tout le document, je sauvegarde aussi des bouts. J'avais vraiment peur que mon document puisse être corrompu (peur de la boà®te noire), donc j'ai bétonné au maximum.


     


    Le dossier dans AppSupport n'héberge pas que les sauvegardes, il y a plein d'autres trucs dedans ;-)


     


    Merci encore, je vous tiens au courant.


     


    Colas


  • colas_colas_ Membre
    novembre 2014 modifié #4

    Après test, ça ne marche pas. Les bookmarkData changent quand on déplace le fichier.


     


     


    J'ai utilisé



    
[myURL bookmarkDataWithOptions:0
    
includingResourceValuesForKeys:nil
    
relativeToURL:nil
    
error:error] ;

    J'ai aussi essayé avec l'option NSURLBookmarkCreationPreferFileIDResolution.


     


    ça ne change pas le fonctionnement des bookmarkData.


  • colas_colas_ Membre
    novembre 2014 modifié #5

    J'ai aussi testé mon idée avec la date de création d'un document. ça ne peut pas marcher car lorsqu'un fichier est dupliqué, sa date de création est inchangée.


  • colas_colas_ Membre
    #6

    Finalement, ça marche !!


     


    En effet, à  partir d'un bookmarkData, on peut retrouver la VRAIE url du fichier correspondant !!!! (une sorte de spotlight ?)


     


    Mon algo est le suivant


     


    -> j'ouvre le fichier


    -> je récupère le bookmarkData que j'ai sauvé dans un plist


    -> je demande à  ce bookmarkData l'url du fichier associé


    -> si l'url du fichier n'est pas cette url, j'en déduis que le fichier a été copié


Connectez-vous ou Inscrivez-vous pour répondre.