Astuce : empêcher un fichier ou un dossier de synchroniser avec iCloud
Depuis macOS Sierra, iCloud peut synchroniser les deux emplacements où vous êtes le plus susceptible d’enregistrer des fichiers : le dossier Documents et le bureau du système. C’est une option très pratique pour garder plusieurs Mac synchronisés, ou même pour accéder à un fichier que l’on a glissé sur le bureau, depuis un appareil iOS. Par défaut, c’est tout ou rien : si vous activez l’option, tous les fichiers et tous les dossiers seront synchronisés avec iCloud.
Vous voulez activer cette synchronisation, mais garder quelques éléments en local ? Il existe une astuce peu connue : ajoutez un .nosync à la fin du nom du dossier ou du fichier, et il ne sera plus synchronisé par iCloud. En fait, vous n’avez même pas besoin de le placer à la toute fin, vous pouvez le glisser n’importe où, sauf au tout début du nom de fichier1 et cela fonctionnera tout autant.
.nosync, il n’est plus synchronisé avec iCloud, comme le signale d’ailleurs macOS.Cette astuce peut servir à conserver quelques gros fichiers sur le bureau sans remplir totalement votre espace de stockage iCloud. Ou bien synchroniser tous les documents, sauf un dossier sensible qui doit éviter de se retrouver sur des serveurs. Naturellement, vous pourrez retirer la mention .nosync à tout moment, et iCloud reprendra immédiatement la synchronisation du document ou du dossier.
Apple a opté pour une solution moins intuitive que ses concurrents, où l’on peut en général activer ou désactiver les dossiers à synchroniser avec une interface graphique. L’approche d’iCloud correspond néanmoins à la majorité des besoins, et elle offre plus de souplesse, puisque vous pouvez exclure des fichiers en particulier, et pas seulement des dossiers.
-
macOS étant un système basé sur UNIX, il y a une convention à respecter : les fichiers et dossiers qui commencent par un point sont masqués et réservés au système. ↩︎
Cool merci!
Sympa comme astuce, merci !
Super ! Merci :)
Maintenant on attend la suite : pouvoir tout synchroniser sur iCloud et demain y faire une sauvegarde ! Suis orphelin des Time Capsule :/
Et le disque de la nôtre qui contient des années de sauvegarde, de films et de musique vient de tomber en rade, on va essayer de le faire réparer chez un APR...
Moi je sauvegarde sur deux disques + iCloud, mais c’était tellement simple et transparent pour ma mère...
En attendant, j’ai déjà mis tous mes dossiers sur iCloud donc quasiment tous mes fichiers sont dessus, j’y ai même grâce à Onyx mis automatiquement toutes mes captures d’écran dans un dossier synchronisé, mais ce n’est pas possible pour les téléchargements, et difficile pour les dossiers Images et Musiques.
Et puis surtout il manque le système, ou au moins les comptes dans Mail par exemple :/
Mais j’ai espoir au vu de l’enrichissement régulier d’iCloud et d’iCloud Drive ?
Merci pour l'astuce.
S'il y a bien un truc qu'Apple a rendu détestable, c'est bien iCloud, entièrement conçu pour être saturé et faire raquer aussi vite que possible les utilisateurs.
Sur un véritable cloud on peut décider quels dossiers synchroniser et surtout sauvegarder.
A ce petit jeu, pCloud est un des meilleurs: on paye une fois pour toutes pour 2 To de stockage visibles sur le bureau comme un disque dur de réseau et basta.
@switch
Après si je me trompe pas pour 1€ on a 50go il me semble c’est pas excessif, ça fait un macdo à l’année...
Mais personnellement mon iCloud bug et se synchronise comme bon lui semble que mon Mac, des fois directement à la création d’un dossier et parfois j’attend 7h avant qu’il se synchronise... payer pour ça même pas chère c’est assez gênant
1 € / mois pour 50 Go n'est pas très cher en effet, mais sur la durée…
Mais à titre personnel j'ai besoin de bcp plus d'espace et de sauvegarder (je n'aime pas les synchros, trop dangereuses car donnant une fausse sensation de sécurité) sur un cloud, j'ai donc opté pour pCloud 2 To "lifetime" qui offre un confort très supérieur à iCloudDrive avec un "vrai" disque de réseau visible sur le bureau (et une surcouche de chiffrage pour mes données).
@switch
Je connais pas pcloud, j’ai opté pour drive car plus simple vu que intégré au mac et iPhone
pCloud est parfaitement intégré à iOS, donc aucun souci pour accéder à tous mes dossiers (et pas seulement "Bureau"&"Documents" de mon Mac…).
Bien sur on peut ajouter manuellement des dossiers à iCloudDrive, mais l'approche de pCloud est bien plus fiable: j'ai sur pCloud ce que je décide d'y placer, et il ne sera pas encombré par les éléments temporaires placés sur mon bureau.
C'est une approche qui exige plus de responsabilité de la part de l'utilisateur, mais moins risquée que l'approche "synchronisation" d'iCloud qui peut entraîner des pertes de données.
Mais on peut aussi utiliser une TimeCapsule pour y stocker des fichiers qui seront accessibles de partout, ou encore plus fiable, un NAS.
@switch
Je ne comprends pas. S'il est aussi intégré à iOS, il faut bien un process de synchronisation pour retrouver les mêmes éléments sur l'ensemble de ses devices, non ?
Tu confonds la synchronisation où les données sont physiquement présentes dans tous les appareils synchronisés et le stockage distant.
Dans le stockage distant, on utilise une application installée sur son iPhone pour accéder aux répertoires des données stockées dans le cloud.
Pour accélérer le processus, l'application utilise quelques centaines de Mo à quelques Go sur l'iPhone (ou le Mac) comme "cache local" permettant d'afficher les vignettes des photos par exemple.
Si on a besoin d'ouvrir le document pour travailler avec, il faut le télécharger (soit le copier physiquement, soit le charger directement en RAM (plus risqué car nécessitera que l'accès au réseau soit toujours présent et assez rapide au moment de l'enregistrement du document) sur son iPhone ou sur son Mac pour l'exploiter dans l'appli de son choix.
@switch
OK j'ai compris le mode de fin. Cela nécessite donc une connexion continue pour travailler sur un document afin qu'il soit disponible partout avec ses dernières. MAJ.
@switch
PCloud n’a aucune intégration via un devkit dans les apps Mac ou iOS :(
Vous avez une astuce pour protéger par mot de passe Fichiers sous Mac et iOS? Merci
@Brtrnd
J'utilise deux systèmes afin de couvrir l'ensemble de mes services Cloud.
https://www.encryptedcloud.com - entièrement gratuit.
https://cryptomator.org - seul l'app iOS est payante.
Et ils possèdent tous les deux des apps iOS.
Excellent !!! ?
L'article aurait mérité un petit sourcing de l'astuce...
@robert.valmore
Ben oui, c'est et c'est bien le cas pourtant… ?
Ahhhhhhhh merciiiiiiiii ???
Excellente astuce !
Et bah, j’aurais jamais trouvé tout seul :p
Ce que j'aimerais arriver à faire c'est de laisser des fichiers seulement en ligne pour libérer de la place sur mon disque à la manière de Dropbox avec sa fonction Smart Sync. Apparement ce n'est pas possible avec iCloud à moins de laisser le système décider tout seul du fichier qu'il va laisser en ligne en cas de saturation du disque. Si quelqu'un a une astuce je suis preneur. ^^
Et si on fait le contraire, qu'on renomme les fichiers déjà present sur iCloud avec un .nosync est ce que ça va les empêcher de se synchro avec le dossier iCloud local ?
@LogBoy
- En effet, iCloud gère tout tout seul, l'unique option est de garder 100 % des éléments en local ;
- L'ajout de .nosync va en fait supprimer le dossier d'iCloud et de tous les Mac. Ce n'est donc pas une bonne idée pour cet usage…
@Nicolas Furno
C'est bien ce qui me faisait peur donc aucune solution pour faire de la pure sauvegarde en espérant qu'un jour Apple decide de changer ça. Merci pour l'info en tout cas. ^^
Tripmode (payant) est parfait. Je navigue entre maison et boulot avec ça. Avec la connexion mobile c'est parfait, il reconnait de lui même le partage ou une ligne fixe. Mais dans ce cas on bloque iCloud ou autre pour limiter les datas.
Très bonne astuce !
Mais moi aussi ce qui me manque le plus c'est de pouvoir supprimer des dossiers en local tout en les conservant dans iCloud.
Ce que tu veux c'est de la sauvegarde, là ou iCloud te propose seulement de la synchronisation…
@ Switch : « Ce que tu veux c'est de la sauvegarde, là ou iCloud te propose seulement de la synchronisation… »
Non, ce qu’il demande ce n’est pas de la sauvegarde, mais uniquement du stockage distant (puisqu’il ne veut pas conserver de copie locale).
On peut faire les deux.
Exemple: j'utilise une application de sauvegarde pour sauvegarder automatiquement les photos de l'année (stockées sur mon Mac) dans un dossier sur pCloud drive. En début d'année suivante je déplace manuellement ce dossier sauvegardé dans un autre dossier sur pCloud Drive (contenant les photos des années précédentes).
Donc au final ma sauvegarde est devenue un stockage distant par un simple déplacement de dossier. Je pourrais même automatiser ce déplacement mais dans le cas cité ça va plus vite de le faire manuellement.
@ Switch : « On peut faire les deux. »
Je n’ai pas dit qu’on ne pouvait pas faire les deux — j’ai juste précisé que ce qu’il demandait dans le commentaire auquel tu as répondu, ce n’était pas de la sauvegarde mais juste du stockage distant.
Olala merci ??
Berk !!!
Pas au sujet de l’article lui-même, mais au sujet de l’approche retenue par Apple (et même si elle n’était pas destinée à un usage public). Il est possible de mettre toutes sortes d’attributs étendus sur les fichiers et dossiers, Mac OS en profite (enfin !) depuis quelques années déjà pour proposer un système de tags riche, et tout ce qu’Apple trouve à utiliser pour marquer des fichiers, c’est la solution toute pourrie de modifier leur nom ?!?
En comparaison des efforts qui ont été déployés aux débuts de Mac OS X pour proposer la moins mauvaise gestion possible de cette aberration que constitue l’usage des extensions de noms de fichiers pour indiquer leur type, on a ici l’impression d’un gros retour en arrière.
L’ingénieur qui a glissé ça danas le code, c’est le fils de celui qui nous avait pondu les fichiers .DS_Store, non ? :-)
Les attributs étendus, encore un truc naze…
Rien de plus simple que d'effacer les attributs étendus, avec une commande shell ou plus simplement par un simple transit du document sur une autre plateforme ou un simple disque de réseau.
Les attributs étendus sont un truc que chaque plateforme gère dans son coin et qui aurait été bien mieux intégré en tant que métadonnées DANS le document et pas en dehors de celui-ci.
Donc l'idée de placer cette "extension" dans le nom du dossier/document est certainement le meilleur choix que pouvait faire Apple.
@ Switch : « Les attributs étendus, encore un truc naze… »
C’est au contraire quelque chose de très utile pour utiliser un système de fichiers au delà d’un fonctionnement ultra-basique. Quelque chose qui aurait dû être présent dès le début dans tous les systèmes de fichiers.
« Rien de plus simple que d'effacer les attributs étendus »
Oh, que si, il y a quelque chose de plus simple : modifier le nom d’un fichier !
Et non seulement c’est simple, mais en plus il s’agit d’une opération parfaitement normale que tout utilisateur s’attend à pouvoir faire sans conséquence inattendue sur une synchronisation ou non du fichier concerné.
« ou plus simplement par un simple transit du document sur une autre plateforme ou un simple disque de réseau. »
Une autre plateforme, oui, hélas. Un disque réseau, normalement, non.
Mais de toute façon, ces deux cas ne sont absoluments pas gênants pour ce dont on parle ici, puisque les fichiers à synchroniser avec iCloud ne sont ni sur une autre plateforme, ni sur un disque réseau.
« Les attributs étendus sont un truc que chaque plateforme gère dans son coin et qui aurait été bien mieux intégré en tant que métadonnées DANS le document et pas en dehors de celui-ci. »
Intégrer ces métadonnées dans le document, qu’est-ce à dire ? Que tout format de fichier devrait obligatoirement intégrer une zone de contenu (et taille) variable permettant d’enregistrer des attributs étendus n’ayant rien à voir avec ce format ?
Hmmm… c’est un peu la même idée que dire que tout format de système de fichiers aurait dû intégrer (et gérer correctement) ce concept depuis toujours, mais c’est encore moins réalisable après coup, contrairement à la gestion de ces attributs au niveau du FS.
« Donc l'idée de placer cette "extension" dans le nom du dossier/document est certainement le meilleur choix que pouvait faire Apple. »
Non, c’est le plus stupide, comme je l’ai déjà expliqué. Aucun besoin de revenir là-dessus. Personne ne sensé ne pourrait prétendre le contraire.
- Je n'ai rien contre les attributs étendus, même si je les évite autant que possible.
- Les attributs sont bien corrélés au noms de fichiers dans chaque dossier, mais modifier le nom d'un fichier (dans les règles de l'art, avec le Finder par exemple) ne modifie pas le moins du monde ses attributs (et encore heureux !)
- Par contre déplacer sauvagement (via une commande shell perl par exemple) un fichier d'un dossier à un autre, et non seulement les attributs ne "suivront" pas, mais ils resteront enregistrés dans leur répertoire d'origine (sic !)
- Je passe sur le non transfert des attributs d'un document placé sur un disque de réseau (via AFP en tout cas, pour SMB je ne sais pas)
- Certains attributs sont très utiles et doivent restés gérés par le File System, mais d'autres, comme les commentaires SpotLight ou les tags (facilement modifiables par l'utilisateur) auraient du être placées comme métadonnées dans chaque fichier.
- Les grands éditeurs d'OS auraient du se mettre d'accord sur une architecture de métadonnées utilisables sur tous les OS.
Ils ne l'ont pas fait, et c'est dommage, et du coup il existe de nombreux types de métadonnées et chaque application les gère à sa façon.
Par chance il existe quand même des "standards" d'encodage comme Exif et XMP, etc…
- Apple ne s'est pas pris la tête en intégrant cette pseudo extension .nosync dans le nom du fichier/dossier, mais à sa décharge on ne peut pas faire plus simple pour l'utilisateur puisque cette donnée est facilement visible.
- Bien sur, il aurait été possible de placer une case à cocher "Ne pas synchroniser sur iCloud" dans la fenêtre d'informations, et gérer ça en attributs étendus, mais ça viendra peut-être dans une future version de macOS.
@ Switch : « Par contre déplacer sauvagement (via une commande shell perl par exemple) un fichier d'un dossier à un autre, et non seulement les attributs ne "suivront" pas, mais ils resteront enregistrés dans leur répertoire d'origine (sic !) »
Non. Avec un move en Perl, comme avec un mv en bash ou csh ou avec n’importe quelle fonction utilisant correctement le système de fichiers, les attributs « suivent » évidemment le fichier — ce qui est parfaitement normal, puisqu’ils sont attachés au fichier dans le système de fichiers (c’est le principe même des attributs étendus). Tu peux le vérifier facilement avec un « ls -l@ » sur ton fichier avant et après le déplacement.
J’ai l’impression que tu confonds les attributs étendus et les fichiers ._* utilisés par Mac OS pour stocker les ressources et métadonnées des fichiers sur les systèmes de fichiers non natifs (autres que HFS+ et APFS, en gros). Cette dernière approche est en effet (très) fragile et ce serait sympa de voir Apple trouver une meilleure solution (en exploitant au maximum les capacités de chaque système de fichiers, notamment), mais elle n’a rien à voir avec ce dont on discutait ici.
Là, on parle d’utiliser les attributs étendus pour la synchronisation des dossiers Bureau et Documents, donc dans le dossier home d’un utilisateur. Dossier qui se trouve dans 99,9 % des cas sur un volume en HFS+ ou APFS, où les attributs étendus sont donc correctement gérés. Il n’y aurait donc aucun souci à les utiliser pour cette fonction. C’est précisément le genre de chose pour quoi ils sont faits.
« Certains attributs sont très utiles et doivent restés gérés par le File System, mais d'autres, comme les commentaires SpotLight ou les tags (facilement modifiables par l'utilisateur) auraient du être placées comme métadonnées dans chaque fichier. »
« Dans » les fichiers, ça veut dire faire partie du format de fichier — irréaliste, donc, et non souhaitable. La place de ces trucs est dans le système de fichiers, et c’est d’ailleurs là qu’ils sont depuis 1984.
« Les grands éditeurs d'OS auraient du se mettre d'accord sur une architecture de métadonnées utilisables sur tous les OS. »
En effet.
Mais ça commence à se faire un peu avec les attributs étendus, qui se ressemblent dans le principe sur les divers FS qui les supportent.
« mais à sa décharge on ne peut pas faire plus simple pour l’utilisateur »
« Bien sur, il aurait été possible de placer une case à cocher "Ne pas synchroniser sur iCloud" dans la fenêtre d'informations, et gérer ça en attributs étendus »
Ben voilà : il était parfaitement possible de faire plus simple (et en même temps bien plus efficace).
Le fichier d’information aurait été plus discret
Punaise c’est invivable macgen iOS sans bloqueur de pub.
Il existait autrefois quelque chose de parfaitement bien intégré au Mac, qui s'appelait Mobile.me, mais un génie à Apple a décidé que tout dans le nuage devait être automatique et systématique. Comme j'ai plusieurs vies (pro, famille, clubs,...) et que je ne souhaite pas tout mélanger, iCloud est pour moi inutilisable.