Renommer Un Dossier = Le Supprimer Et Le Reuploader ?

[trucmuche2005]

Bonjour !

Je viens de renommer un répertoire dans mon dossier synchronisé avec CloudStation. Et toutes les 5 secondes, j'ai une notification de la CloudStation sur le mac disant que "33 fichiers ont été mis à jour" puis "35 fichiers ont été mis à jour" puis "23 fichiers ont été mis à jour" etc...

C'est donc comme si le fait d'avoir renommé le répertoire avait provoqué sa suppression du NAS puis le re-upload du dossier entier.

Ce n'est quand même pas comme cela que ca se passe, rassurez-moi... ??? :-s

Trucmuche

[DjMomo]

Ben si. La synchronisation en général, c'est supprimer ce qui n'existe plus et créer ce qui n'existe pas...

[trucmuche2005]

Vous avouerez quand même que c'est complètement stupide... Pourquoi l'action n'est-elle pas prise en compte plutôt que le résultat ? Ce sera pour la prochaine "révolution" du cloud ?

[Kramlech]

Donc tu voudrais que le cloud espionne et interprète complètement tes moindres actions ?

Sinon, quand tu renommes un fichier, explique moi comment il peut savoir que c'est une modification, et pas la suppression d'un fichier, et la création d'un autre fichier qui n'a rien à voir ?

[trucmuche2005]

Il ne faut pas faire comme si c'était un doux rêve d'un illuminé... Bon nombre de choses qui sont possibles aujourd'hui et qu'on utilise couramment étaient il y a quelques mois/années de l'ordre de l'idéal.

Dans le finder, activer l'opération de "renommer" est faite par l'utilisateur. Si le démon cloud avait un "écouteur" auquel le finder puisse parler (je pense à un truc du genre eventListener de l'ActionScript), le finder pourrait transmettre au démon cloud l'information disant que tel répertoire a été renommé avec tel nom.

Traitez moi de fou ou d'utopiste si vous voulez, je m'en fiche :-) Je vous souhaite simplement de savoir simplement reconnaître avec humilité que certaines actions ou certains fonctionnements sont stupides.

[Kramlech]

Et si le demon cloud n'est pas actif lors de l'action sur le répertoire, il se passera quoi ?

Le fonctionnement actuel permet de prendre en compte cette contrainte. Ce n'est peu être pas l'idéal, mais ou moins cela fonctionne!!!

Certains fonctionnements peuvent paraître stupides, mais bien souvent ils sont la conséquence de contraintes ou d'architectures avec lesquelles il est obligatoire de composer ...

[trucmuche2005]

Et si le demon cloud n'est pas actif lors de l'action sur le répertoire, il se passera quoi ?

Dans ce cas, je comprendrais le fonctionnement actuel : obligé de faire l'état des différences et de se débrouiller. Mais quand il est actif (c'est à dire tout le temps chez moi puisqu'il est lancé au démarrage), c'est bête.

Certains fonctionnements peuvent paraître stupides, mais bien souvent ils sont la conséquence de contraintes ou d'architectures avec lesquelles il est obligatoire de composer ...

Bien sûr, mais un certain temps seulement... et c'est ce que je disais dès mon deuxième post ici... Cela dit, je ne suis pas du tout expert en MacOS puisque cela fait moins d'un an que j'en possède un mais il me semble que ce genre de fonctionalité est déjà implémenté dans le système... C'est donc possible à l'heure actuelle... Chaque opération sur le filesystem crée un eventstream, envoie un événement système qu'il suffit d'attraper dans l'application tierce genre démon Cloud. Une page intéressante chez MacDeveloper ici. Une autre ici où l'auteur a une solution satisfaisante qui attrape ces evenements et qui a une méthode

fileWasRenamed... et son code source est

là (à partir de la version 0.9).

Preuve par neuf ? :-)

[Kramlech]

Je ne connais pas le monde Mac, et si tu dis que c'est possible, tu as sans doute raison.

Je me plaçais à un niveau plus général : le monde des synologistes n'est pas composé que de Mac, mais aussi de Windows, Linux, etc ...

Est-ce que le type d'architecture que tu proposes est aussi possible dans ces mondes là ?

Dans la cas contraire, est-il raisonnable de proposer un outils qui ait des modes de fonctionnement fondamentalement différents selon le système sur lequel il tourne ?

Quand je parlais d'architecture, je ne pensais pas aux fonctionnalité Mac, mais bien d'architecture compatible multi système ...

Il s'agit donc là d'un plus vaste débat ....

PS : Je suis d'accord avec toi quand tu dis que choses vont probablement évoluer, mais si je me suis permis de réagir, c'est en raison de ton affirmation péremptoire :

Vous avouerez quand même que c'est complètement stupide... Pourquoi l'action n'est-elle pas prise en compte plutôt que le résultat ? Ce sera pour la prochaine "révolution" du cloud ?

Et personnellement, je préfère avoir un outil qui répond aux finalités pour lesquelles il a été construit (pour rappel : maintenir synchronisés des fichiers sur plusieurs machines), que de me préoccuper de la manière dont il le fait dans une première version (ce qui pourra toujours évoluer lors des versions ultérieures).

[trucmuche2005]

L'adaptation est dépendante du système d'exploitation, c'est évident. Exactement comme le développement d'un démon CloudStation pour mac, d'un autre pour Windoze et un troisième pour Linux... C'est une légère modification de chacun de ces trois démons qui serait nécessaire, rien de plus. Cela fait donc partie du développement des clients cloudstation pour chaque OS.

Sous Mac, c'est possible, comme je l'ai déjà dit. Sous Linux, il me semble (voir ici) que c'est du ressort de inotify (qui semble être en standard inclus dans les noyaux actuels mais c'est à vérifier). Sous Windoze, il y a aussi un événement filesystemWatcher.changed (voir ici). Donc à chaque coup, l'événement "rename" est attrapable dans un dossier que l'on surveille...

Donc OUI, c'est possible dans chaque système supporté par Syno et si les techniques modernes ne sont pas celles que j'ai citées ci-dessus, il y en a forcément d'autres puisque cela a au moins existé dans le passé proche... il suffirait de l'écrire dans les démons CloudStation pour chaque OS supporté (une bonne partie doit déjà l'être donc il suffit sans doute de compléter) !

Et personnellement, je préfère avoir un outil qui répond aux finalités pour lesquelles il a été construit (pour rappel : maintenir synchronisés des fichiers sur plusieurs machines), que de me préoccuper de la manière dont il le fait dans une première version (ce qui pourra toujours évoluer lors des versions ultérieures).

Que cela fonctionne, c'est une chose et c'est ce que tout le monde veut d'abord, bien sûr.

Que cela fonctionne INTELLIGEMMENT, c'est une autre chose... Et là, en l'occurence, il y aurait beaucoup d'économies faites à implémenter cette fonctionnalité simple ! Si je décide de renommer un dossier de 50Go sans toucher au contenu, perso, je serai heureux si c'est fait instantanément sur le NAS comme sur tous les clients... Tandis que là, je vais râler de devoir perdre du temps simplement parce que la synchro, stupidement programmée, fasse un delete, un upload puis un download...

Et quand j'écris "stupide", si c'est cela que tu trouves péremptoire, je maintiens, je persiste et signe... Si tu trouves cela intelligent comme manière de procéder, on n'a pas la même notion d'intelligence (mais c'est pas grave, on peut continuer à échanger nos points de vues, avec plaisir ;-))...

[Lurik]

Cette manière "intélligente" de faire serait effectivement la meilleure. J'y ai déjà songé pour les sauvegardes qui fonctionnent aussi en recopiant les répertoires dès que le nom à changé.

Mais dans le fonctionnement que tu décris, attraper les événements pour les transmettres aux autres clients ne marche que si tout le monde est connecté. Or le but premier du cloud est de permettre la synchronisation en mode déconnecté.

=> la mémorisation de tous les événements est possible, maisil peut être nécessaire d'en mémoriser vraiement beaucoup.

=> comment faire pour synchroniser un répertoire si 2 clients on généré des listes d'événements sur le même dossier? on prend le premier qui se connecte? le dernier qui parle à raison?

Du fait du fonctionnement off line du cloud, je pense que la solution la plus simple et fiable reste encore la comparaison des résultats des actions => cela prend du temps pour un simple renomage de répertoire.

Le fonctionnement "par événement" me parrait plus adapté dans le cas de client-serveur qui sont en permanence connecté.

Comme exemple, j'ai en tête les nas d'un concurent de syno : tu peux mettre 2 nas surel réseau, l'un étant le maitre de l'autre et toute modification dans les fichiers sur le premier est automatiquement répercuté sur le second. En cas de panne du nas maitre, le secours prends le relais à chaud sans que les clients ne voit de différence.