Pour passer le temps: aliases qui engraissent

Le
J.P
En septembre 2009, déjà sous SL, mes aliases pesaient 4Ko.
Ceux que je vois créés en octobre 2010 et depuis (toujours sous SL)
pèsent 1Mo.
1- pourquoi ?
2- un truc pour faire passer ceux de 1Mo à 4Ko ?
vu qu'à l'usage, je n'y vois aucune diférence. :-)

--
Jean-Pierre
Vos réponses Page 7 / 11
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
pdorange
Le #26431940
J.P
> Mes alias sont sur la même machine, sur le même disque.
Ce serait donc des icones personalisées qui font le poids supplémentaire
?

Non, ce sont des icône basiques de dossiers, la seule différence étant
leur date de création.
Depuis 2010, mon SL 10.6.8 semble ne savoir faire que des icônes de 1Mo
pour l'alias d'un dossier basique.
Ex.: j'ai un dossier et son alias de 2009: il pèse 4Ko (700o)
Je fais aujourd'hui un alias du même dossier: il pèse 1Mo (1 037 647 o)

Je suis ici aussi sous SL 10.6.8.
Si je crée un alias (raccourci) d'un dossier, il fait en effet environ
1Mo.
Des alias crée en 2014 font aussi 1Mo.
Par contre des alais de dossier crées en 2011 font env. 510 ko (la
moitié). Et j'étais aussi probablement en 10.6.8 a ce moment là, mais
sans certitude...
nota :
Un alias (raccourci en français) est un lien MacOS version un original
(fichier ou dossier c'est parail), local ou distant. La taille de
l'alias ne dépend pas de la taille ou du contenu de l'original.
Son contenu est difficilement accessible puisque c'est un raccouric
d'assez bas niveau dans le système et les librairies d'accès aux
fichiers ne le voient pas, le système le montre aux logiciels comme
l'original (c'est transparent). Donc on ouvre ou édite toujours la
source, pas le fichier alias.
Par ailleurs ce qui différencie un aliais d'un lien symbolique
(Unix/Mac) c'est que l'alias reste valable même si la source est renommé
ou déplacés (sur le même volume).
--
Pierre-Alain Dorange Moof Ce message est sous licence Creative Commons "by-nc-sa-2.0"
mv
Le #26431942
Pierre-Alain Dorange
C'est pas évident à démêler tout ça.
Voir : Message-ID:

Ca parait assez clair pourtant, l'ajout d'un icone augmente très
sensiblement la taille de l'alias.

Bien sûr mais dans l'exemple que j'ai cité, l'icône est celle du fichier
déjà présente... Ce n'est pas une icône nouvelle.
Est-ce que, lors du copier/coller de l'icône, le Finder convertit une
icône d'un certain format en icônes de différents formats ?
--
Michel Vauquois
85 nuances d'automne :
someone
Le #26431948
Pierre-Alain Dorange
pehache
> En passant un petit rappel, il existe un outil de synchro très efficace,
> puissant er reconnu intégré a MacOS X. C'est la commande rsync.
> Certes c'est de la ligne de commande mais c'est très efficace et
> disponible de base.
Il ne te reste plus qu'expliquer à Benoît comment mettre en oeuvre rsync
pour arriver à une solution similaire à celle de GD.

C'est pas (trop) compliqué (mais ça reste de la console), pour une
sauvegarde synchronisée la syntaxe de base est :
rsync -av [source] [destination]

Et pour que ça synchronise en permanence comme Dropbox ou Google Drive ?
Un cron ?
--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
pdorange
Le #26431951
SbM
> Il ne te reste plus qu'expliquer à Benoît comment mettre en oeuvre rsync
> pour arriver à une solution similaire à celle de GD.
C'est pas (trop) compliqué (mais ça reste de la console), pour une
sauvegarde synchronisée la syntaxe de base est :
rsync -av [source] [destination]

Et pour que ça synchronise en permanence comme Dropbox ou Google Drive ?
Un cron ?

Oui bien sur, mais il vaut mieux éviter cron (qui d'ailleurs ne doit
plus exister sur les systèmes récents) et passer directement aux tâches,
bien plus compatible et un peu plus souple.
Mais ce ne sera pas vraiment "permanent" comme dropbox, car le
fonctionnement est un tout petit peu différent.
Pour être permanent, il faudrait lancer rsync très souvent et que le
dossier soit pas trop gros (pas trop de fichiers).`
rsync est très adapté pour faire des sauvegardes (par synchronisation),
des archives, etc... plus peut être que pour avoir une synchro temps
réel... Quoique en fait le fonctionnement de dropbox doit être
similaire, parce qu'il faut bien scanner la source pour savoir si il y a
des modifs...
--
Pierre-Alain Dorange Moof Ce message est sous licence Creative Commons "by-nc-sa-2.0"
benoit
Le #26431955
Pierre-Alain Dorange
J.P
> > Mes alias sont sur la même machine, sur le même disque.
>
> Ce serait donc des icones personalisées qui font le poids supplémentaire
> ?
Non, ce sont des icône basiques de dossiers, la seule différence étant
leur date de création.
Depuis 2010, mon SL 10.6.8 semble ne savoir faire que des icônes de 1Mo
pour l'alias d'un dossier basique.
Ex.: j'ai un dossier et son alias de 2009: il pèse 4Ko (700o)
Je fais aujourd'hui un alias du même dossier: il pèse 1Mo (1 037 647 o)

Je suis ici aussi sous SL 10.6.8.
Si je crée un alias (raccourci) d'un dossier, il fait en effet environ
1Mo.
Des alias crée en 2014 font aussi 1Mo.
Par contre des alais de dossier crées en 2011 font env. 510 ko (la
moitié). Et j'étais aussi probablement en 10.6.8 a ce moment là, mais
sans certitude...

Une suggestion :
Quand est-ce-que le système a permis l'affichage des icones en très,
très grand format ? Les premières versions génèraient peut-être, pour
les alias, des icones de dossiers contenant toutes les tailles (du petit
au très grand) et ils étaient inclus dans le l'alias. Ensuite l'alias
n'a été qu'un pointeur vers les icones contenus dans le Finder.
Les applications contiennent (?) les différents icones (appli,
documents...) en tant que fichiers/images séparés et un alias pointe
vers ces fichiers. L'ancienne version du Finder, en tant qu'application,
ne savait pas gérer ça et incluait donc dans un alias toutes les
versions d'icones de dossier. Maintenant c'est aussi un pointeur.
Il faudrait ouvrir un alias avec un TextWrangler ou équivalent qui sache
lire le contenu d'un alias du Finder et voir ce qu'il y a dedans.
--
On s'occupe de l'étiquette qu'une fois les vendanges terminées.
pehache
Le #26431956
Le 14/04/2017 à 12:06, Pierre-Alain Dorange a écrit :
SbM
> Il ne te reste plus qu'expliquer à Benoît comment mettre en oeuvre

rsync
> pour arriver à une solution similaire à celle de GD.
C'est pas (trop) compliqué (mais ça reste de la console), pour une
sauvegarde synchronisée la syntaxe de base est :
rsync -av [source] [destination]

Et pour que ça synchronise en permanence comme Dropbox ou Google Drive ?
Un cron ?

Oui bien sur, mais il vaut mieux éviter cron (qui d'ailleurs ne doit
plus exister sur les systèmes récents) et passer directement aux tâches,
bien plus compatible et un peu plus souple.
Mais ce ne sera pas vraiment "permanent" comme dropbox, car le
fonctionnement est un tout petit peu différent.
Pour être permanent, il faudrait lancer rsync très souvent et que le
dossier soit pas trop gros (pas trop de fichiers).`
rsync est très adapté pour faire des sauvegardes (par synchronisation),
des archives, etc... plus peut être que pour avoir une synchro temps
réel... Quoique en fait le fonctionnement de dropbox doit être
similaire, parce qu'il faut bien scanner la source pour savoir si il y a
des modifs...

Dropbox (ou autres du même genre) ne scanne la source qu'au démarrage de
l'appli. Ensuite il se base sur les événements de l'OS pour savoir en
temps réel quels fichiers sont modifiés/ajoutés/supprimés/déplacés...
S'il devait tout rescanner en permanence ce ne serait pas efficace je
pense.
pehache
Le #26431957
Le 14/04/2017 à 10:40, Pierre-Alain Dorange a écrit :
pehache
En passant un petit rappel, il existe un outil de synchro très

efficace,
puissant er reconnu intégré a MacOS X. C'est la commande rsync.
Certes c'est de la ligne de commande mais c'est très efficace et
disponible de base.

Il ne te reste plus qu'expliquer à Benoît comment mettre en oeuvre rsync
pour arriver à une solution similaire à celle de GD.

C'est pas (trop) compliqué (mais ça reste de la console), pour une
sauvegarde synchronisée la syntaxe de base est :
rsync -av [source] [destination]
Qui permet de faire une archive (a), qui recopie tout (en suivant les
liens et liens symboliques) et d'afficher à l'écran ce qui se passe (v).
On peut compresser la sauvegarde avec (z).

-z ne compresse pas la sauvegarde, mais compresse les données
transférées, qui sont décompressées à destination.
Et à mon avis ca n'a de sens que quand on utilise rsync en mode
client/serveur (avec un démon rsyncd qui tourne sur un serveur distant)
Si les volumes sont distants on peut/doit les monter avant (mount) sinon
la sauveagrde échoue (mais n'éfface rien).
On peut aussi intégrer des commandes comme ssh, qui permettent de se
conencter à distance sur un autre poste (Mac ou Linux) de manière
sécurisé pour sauvegarder "ailleurs".
Des exemples (an anglais) :
La doc (en français) :
On trouve plusieurs logiciels de sauvegarde / synchronisation basé sur
rsync, qui ne sont que des interfaces graphiques (plus conviviale que
l'austère console), commes RSyncX, luckyBackUp, Grsync, arRsync,
Unisson...
rsync est vraiment très puissant, solide et efficace.
Ca permet de faire a peu prêt tout concernant de la synchro et des
sauvegarde et c'est multiplateforme.
Ca évite l'achat de logiciels de sauvegarde plus ou moins efficace...


On peut trouver plein de réelles qualités à rsync, mais la comparaison
avec un outil type Google Drive n'a pas vraiment de sens, même en mettant
de côté l'étape de mise en oeuvre d'une solution rsync (allant jusqu'à
avoir des notifications sur l'état du fonctionnement, genre pour ne pas
découvrir au bout d'un mois que la synchro ne se fait plus, etc...) :
rsync fait une synchronisation unidirectionnelle à la demande, alors que
celle de GD est bidirectionnelle en temps réel, avec gestion des conflits
de synchronisation (genre un fichier modifié des deux côtés en même
temps).
GD fait la synchronisation temps réel sur un nombre quelconque de clients
synchronisant les mêmes fichiers, ce qui complique notoirement la gestion
des conflits de synchronisation : essaie de réfléchir à faire la même
chose avec des rsync sans risquer de perdre aucun fichier, et tu vas vite
avoir mal à la tête.
Maintenant si on restreint l'utilisation de GD à celle d'un simple espace
de sauvegarde, c'est un peu différent puisqu'un synchro unidirectionnelle
à la demande -donc rsync- est alors bien adaptée. Mais il faut disposer
d'un espace de stockage en ligne de bonne taille (Benoît utilise GD parce
qu'il y dispose de 1To), avec un accès SSH ou sur un serveur qui peut
exécuter un démon rsyncd... Et ça peut vite coûter bonbon.
mv
Le #26431961
Benoit
Il faudrait ouvrir un alias avec un TextWrangler ou équivalent qui sache
lire le contenu d'un alias du Finder et voir ce qu'il y a dedans.

Peut pas...
NB TextWrangler est devenu obsolète et est maintenant remplacé par la
version non enregistrée de BBEdit.
Cordialement.
--
Michel Vauquois
85 nuances d'automne :
benoit
Le #26431984
M.V.
Benoit
Il faudrait ouvrir un alias avec un TextWrangler ou équivalent qui sache
lire le contenu d'un alias du Finder et voir ce qu'il y a dedans.

Peut pas...
NB TextWrangler est devenu obsolète et est maintenant remplacé par la
version non enregistrée de BBEdit.

Merci pour l'info, je me mets à jour de suite.
--
On s'occupe de l'étiquette qu'une fois les vendanges terminées.
J.P
Le #26431989
In article (Pierre-Alain Dorange) wrote:
Par ailleurs ce qui différencie un aliais d'un lien symbolique
(Unix/Mac) c'est que l'alias reste valable même si la source est renommé
ou déplacés (sur le même volume).

Sous 10.6.8
Je viens de faire l'essai de renommer puis déplacer (sur le même volume
système) un dossier pointé par un lien symbolique issu du "merveilleux"
script de JB.
La seule chose qui change est que le lien symbolique perd son icône qui
devient celle d'une page blanche et garde la petite flèche en bas à
gauche.
Dans les deux cas (déplacement, nom) le "lien symbolique JB" retrouve
l'original et l'ouvre.
Peut-être faut-il un logout pour que le lien soit cassé ?
--
Jean-Pierre
Publicité
Poster une réponse
Anonyme