/sw/bin/rsync --help rsync version 3.0.6 protocol version 30 [snip] -E, --executability preserve the file's executability -A, --acls preserve ACLs (implies --perms) -X, --xattrs preserve extended attributes
rsync --help rsync version 2.6.9 protocol version 29 [snip] -E, --extended-attributes copy extended attributes
j'utilse : ${RSYNC_3} -qaEu --delete ${SRC_DOCUMENTS_DIR} ${DST_DOCUMENTS_DIR} avec RSYNC_3=/usr/local/bin/rsync (version 3.0.7 patchée et fraichement installée)
avec la version 3 que j'ai ici, le -E n'est plus le même que dans la version de Snow Minet.
j'ai trouvé ça sur : <http://voice.firefallpro.com/2006/03/backing-up-with-launchd-and-rsync- in.html> le guide d'install de rsync 3 sur : <http://www.bombich.com/mactips/rsync.html>
Perso je ferais plus confiance à Bombich, qu'à FireFall. Il dit ceci : I'm happy to report that rsync 3.0.6 passes the backup bouncer test suite with flying colors. Here are the results of my testing (using aNHAX --fileflags --force-change):
-- Nicolas Michel
Une Bévue <unbewusst.sein@google.com.invalid> wrote:
Nicolas Michel <NicolasAlex.Michel.remove@epfl.ch> wrote:
>
> Tu as évidement utilisé les options -A et -X
ben non ;-)
/sw/bin/rsync --help
rsync version 3.0.6 protocol version 30
[snip]
-E, --executability preserve the file's executability
-A, --acls preserve ACLs (implies --perms)
-X, --xattrs preserve extended attributes
rsync --help
rsync version 2.6.9 protocol version 29
[snip]
-E, --extended-attributes copy extended attributes
j'utilse :
${RSYNC_3} -qaEu --delete ${SRC_DOCUMENTS_DIR} ${DST_DOCUMENTS_DIR}
avec RSYNC_3=/usr/local/bin/rsync (version 3.0.7 patchée et fraichement
installée)
avec la version 3 que j'ai ici, le -E n'est plus le même que dans la
version de Snow Minet.
j'ai trouvé ça sur :
<http://voice.firefallpro.com/2006/03/backing-up-with-launchd-and-rsync-
in.html>
le guide d'install de rsync 3 sur :
<http://www.bombich.com/mactips/rsync.html>
Perso je ferais plus confiance à Bombich, qu'à FireFall.
Il dit ceci :
I'm happy to report that rsync 3.0.6 passes the backup bouncer test
suite with flying colors. Here are the results of my testing (using
aNHAX --fileflags --force-change):
/sw/bin/rsync --help rsync version 3.0.6 protocol version 30 [snip] -E, --executability preserve the file's executability -A, --acls preserve ACLs (implies --perms) -X, --xattrs preserve extended attributes
rsync --help rsync version 2.6.9 protocol version 29 [snip] -E, --extended-attributes copy extended attributes
j'utilse : ${RSYNC_3} -qaEu --delete ${SRC_DOCUMENTS_DIR} ${DST_DOCUMENTS_DIR} avec RSYNC_3=/usr/local/bin/rsync (version 3.0.7 patchée et fraichement installée)
avec la version 3 que j'ai ici, le -E n'est plus le même que dans la version de Snow Minet.
j'ai trouvé ça sur : <http://voice.firefallpro.com/2006/03/backing-up-with-launchd-and-rsync- in.html> le guide d'install de rsync 3 sur : <http://www.bombich.com/mactips/rsync.html>
Perso je ferais plus confiance à Bombich, qu'à FireFall. Il dit ceci : I'm happy to report that rsync 3.0.6 passes the backup bouncer test suite with flying colors. Here are the results of my testing (using aNHAX --fileflags --force-change):
-- Nicolas Michel
unbewusst.sein
JiPaul wrote:
Et une autre est qu'une copie/sauvegarde d'un alias pointe vers la copie/sauvegarde de l'original si le chemin relatif de l'un vers l'autre reste le même. Chose qui manifestement n'a pas marché dans le cas de la sauvegarde par rsync effectuée par Une Bévue, et qu'il regrette d'ailleurs.
oui, oui, mais je crois qu'il y a "deux" types d'alias, les relatifs et les absolus non ?
je ne me souviens plus comment on crée un alias relatif, si ça existe... -- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
JiPaul <blanc@empty.org> wrote:
Et une autre est qu'une copie/sauvegarde d'un alias pointe vers la
copie/sauvegarde de l'original si le chemin relatif de l'un vers l'autre
reste le même. Chose qui manifestement n'a pas marché dans le cas de la
sauvegarde par rsync effectuée par Une Bévue, et qu'il regrette
d'ailleurs.
oui, oui, mais je crois qu'il y a "deux" types d'alias, les relatifs et
les absolus non ?
je ne me souviens plus comment on crée un alias relatif, si ça existe...
--
« Sur le plus beau trône du monde,
on n'est jamais assis que sur son cul ! »
(Michel de Montaigne)
Et une autre est qu'une copie/sauvegarde d'un alias pointe vers la copie/sauvegarde de l'original si le chemin relatif de l'un vers l'autre reste le même. Chose qui manifestement n'a pas marché dans le cas de la sauvegarde par rsync effectuée par Une Bévue, et qu'il regrette d'ailleurs.
oui, oui, mais je crois qu'il y a "deux" types d'alias, les relatifs et les absolus non ?
je ne me souviens plus comment on crée un alias relatif, si ça existe... -- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
unbewusst.sein
Nicolas Michel wrote:
/sw/bin/rsync --help rsync version 3.0.6 protocol version 30 [snip] -E, --executability preserve the file's executability -A, --acls preserve ACLs (implies --perms) -X, --xattrs preserve extended attributes
bon, OK...
Perso je ferais plus confiance à Bombich, qu'à FireFall.
oui c'est sûr.
Il dit ceci : I'm happy to report that rsync 3.0.6 passes the backup bouncer test suite with flying colors. Here are the results of my testing (using aNHAX --fileflags --force-change):
je n'étais pas allé au bout de la page pensant que ça causait ssh...
bon j'ai juste les options à changer, pas grave, je suis encore "en p^ériode de test", enfin mon script...
-- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
Nicolas Michel <NicolasAlex.Michel.remove@epfl.ch> wrote:
/sw/bin/rsync --help
rsync version 3.0.6 protocol version 30
[snip]
-E, --executability preserve the file's executability
-A, --acls preserve ACLs (implies --perms)
-X, --xattrs preserve extended attributes
bon, OK...
Perso je ferais plus confiance à Bombich, qu'à FireFall.
oui c'est sûr.
Il dit ceci :
I'm happy to report that rsync 3.0.6 passes the backup bouncer test
suite with flying colors. Here are the results of my testing (using
aNHAX --fileflags --force-change):
je n'étais pas allé au bout de la page pensant que ça causait ssh...
bon j'ai juste les options à changer, pas grave, je suis encore "en
p^ériode de test", enfin mon script...
--
« Sur le plus beau trône du monde,
on n'est jamais assis que sur son cul ! »
(Michel de Montaigne)
/sw/bin/rsync --help rsync version 3.0.6 protocol version 30 [snip] -E, --executability preserve the file's executability -A, --acls preserve ACLs (implies --perms) -X, --xattrs preserve extended attributes
bon, OK...
Perso je ferais plus confiance à Bombich, qu'à FireFall.
oui c'est sûr.
Il dit ceci : I'm happy to report that rsync 3.0.6 passes the backup bouncer test suite with flying colors. Here are the results of my testing (using aNHAX --fileflags --force-change):
je n'étais pas allé au bout de la page pensant que ça causait ssh...
bon j'ai juste les options à changer, pas grave, je suis encore "en p^ériode de test", enfin mon script...
-- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
NicolasAlex.Michel.remove
Une Bévue wrote:
JiPaul wrote:
> Et une autre est qu'une copie/sauvegarde d'un alias pointe vers la > copie/sauvegarde de l'original si le chemin relatif de l'un vers l'autre > reste le même. Chose qui manifestement n'a pas marché dans le cas de la > sauvegarde par rsync effectuée par Une Bévue, et qu'il regrette > d'ailleurs.
oui, oui, mais je crois qu'il y a "deux" types d'alias, les relatifs et les absolus non ?
je ne me souviens plus comment on crée un alias relatif, si ça existe...
Les symlink peuvent être relatifs ou absolus.
Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce domaine -- Nicolas Michel
Une Bévue <unbewusst.sein@google.com.invalid> wrote:
JiPaul <blanc@empty.org> wrote:
> Et une autre est qu'une copie/sauvegarde d'un alias pointe vers la
> copie/sauvegarde de l'original si le chemin relatif de l'un vers l'autre
> reste le même. Chose qui manifestement n'a pas marché dans le cas de la
> sauvegarde par rsync effectuée par Une Bévue, et qu'il regrette
> d'ailleurs.
oui, oui, mais je crois qu'il y a "deux" types d'alias, les relatifs et
les absolus non ?
je ne me souviens plus comment on crée un alias relatif, si ça existe...
Les symlink peuvent être relatifs ou absolus.
Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce
domaine
--
Nicolas Michel
> Et une autre est qu'une copie/sauvegarde d'un alias pointe vers la > copie/sauvegarde de l'original si le chemin relatif de l'un vers l'autre > reste le même. Chose qui manifestement n'a pas marché dans le cas de la > sauvegarde par rsync effectuée par Une Bévue, et qu'il regrette > d'ailleurs.
oui, oui, mais je crois qu'il y a "deux" types d'alias, les relatifs et les absolus non ?
je ne me souviens plus comment on crée un alias relatif, si ça existe...
Les symlink peuvent être relatifs ou absolus.
Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce domaine -- Nicolas Michel
unbewusst.sein
Nicolas Michel wrote:
Les symlink peuvent être relatifs ou absolus.
oui, ça je me souviens comment faire, il suffit de l'indiquer, par le path, à la création.
Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce domaine
il y a une TN, obsolète là : <http://developer.apple.com/legacy/mac/library/technotes/tn/tn1188.html> -- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
Nicolas Michel <NicolasAlex.Michel.remove@epfl.ch> wrote:
Les symlink peuvent être relatifs ou absolus.
oui, ça je me souviens comment faire, il suffit de l'indiquer, par le
path, à la création.
Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce
domaine
il y a une TN, obsolète là :
<http://developer.apple.com/legacy/mac/library/technotes/tn/tn1188.html>
--
« Sur le plus beau trône du monde,
on n'est jamais assis que sur son cul ! »
(Michel de Montaigne)
oui, ça je me souviens comment faire, il suffit de l'indiquer, par le path, à la création.
Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce domaine
il y a une TN, obsolète là : <http://developer.apple.com/legacy/mac/library/technotes/tn/tn1188.html> -- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
Patrick Stadelmann
In article <1jhrk59.19ey0pc1dsyhwqN%, (Nicolas Michel) wrote:
Une Bévue wrote:
> MAIS, malheureusement cet alias (sans est bien un) pointe toujours sur > le fichier original, à savoir /another_path/to_a_file
Ce qui me semble normal. C'est ce qui est sensé être la force des alias, tu les déplacent et ils fonctionnent encore.
Oui, l'alias contient des informations permettant d'identifier le volume source. Donc même en copiant un alias sur un autre disque, il pointe toujours vers la même cible.
Par contre, si la cible n'est plus accessible (volume démonté, cible supprimée), le système applique différentes stratégies pour essayer de localiser la cible.
Par exemplke, si on a sur un volume "1" un dossier "Test" qui contient un fichier et un alias vers ce fichier, et que l'on copie ce dossier sur un volume "2", l'alias pointe vers les fichier sur le volume "1".
Mais si on supprimer le dossier "Test" sur le volume "1", l'alias va être corrigé pour pointer sur le fichier correspondant du dossier "Test" sur le volume "2".
> j'ai googelisé, sur ce sujet les réponses sont négatives, du genre : > "rsync étant un truc unix, ça ne s'occupe pas des alias mac os"...
Mais si, mais si ! Sauf que je ne connais pas assez le fonctionnement des alias pour te dire quoi ou comment
Je serais étonné que rsync ne préoccupe des alias, il doit les copier comme n'importe quel autre fichier. Donc le résultat doit être identique à une copie par le Finder.
Patrick -- Patrick Stadelmann
In article <1jhrk59.19ey0pc1dsyhwqN%NicolasAlex.Michel.remove@epfl.ch>,
NicolasAlex.Michel.remove@epfl.ch (Nicolas Michel) wrote:
Une Bévue <unbewusst.sein@google.com.invalid> wrote:
> MAIS, malheureusement cet alias (sans est bien un) pointe toujours sur
> le fichier original, à savoir /another_path/to_a_file
Ce qui me semble normal.
C'est ce qui est sensé être la force des alias, tu les déplacent et ils
fonctionnent encore.
Oui, l'alias contient des informations permettant d'identifier le volume
source. Donc même en copiant un alias sur un autre disque, il pointe
toujours vers la même cible.
Par contre, si la cible n'est plus accessible (volume démonté, cible
supprimée), le système applique différentes stratégies pour essayer de
localiser la cible.
Par exemplke, si on a sur un volume "1" un dossier "Test" qui contient
un fichier et un alias vers ce fichier, et que l'on copie ce dossier sur
un volume "2", l'alias pointe vers les fichier sur le volume "1".
Mais si on supprimer le dossier "Test" sur le volume "1", l'alias va
être corrigé pour pointer sur le fichier correspondant du dossier "Test"
sur le volume "2".
> j'ai googelisé, sur ce sujet les réponses sont négatives, du genre :
> "rsync étant un truc unix, ça ne s'occupe pas des alias mac os"...
Mais si, mais si !
Sauf que je ne connais pas assez le fonctionnement des alias pour te
dire quoi ou comment
Je serais étonné que rsync ne préoccupe des alias, il doit les copier
comme n'importe quel autre fichier. Donc le résultat doit être identique
à une copie par le Finder.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jhrk59.19ey0pc1dsyhwqN%, (Nicolas Michel) wrote:
Une Bévue wrote:
> MAIS, malheureusement cet alias (sans est bien un) pointe toujours sur > le fichier original, à savoir /another_path/to_a_file
Ce qui me semble normal. C'est ce qui est sensé être la force des alias, tu les déplacent et ils fonctionnent encore.
Oui, l'alias contient des informations permettant d'identifier le volume source. Donc même en copiant un alias sur un autre disque, il pointe toujours vers la même cible.
Par contre, si la cible n'est plus accessible (volume démonté, cible supprimée), le système applique différentes stratégies pour essayer de localiser la cible.
Par exemplke, si on a sur un volume "1" un dossier "Test" qui contient un fichier et un alias vers ce fichier, et que l'on copie ce dossier sur un volume "2", l'alias pointe vers les fichier sur le volume "1".
Mais si on supprimer le dossier "Test" sur le volume "1", l'alias va être corrigé pour pointer sur le fichier correspondant du dossier "Test" sur le volume "2".
> j'ai googelisé, sur ce sujet les réponses sont négatives, du genre : > "rsync étant un truc unix, ça ne s'occupe pas des alias mac os"...
Mais si, mais si ! Sauf que je ne connais pas assez le fonctionnement des alias pour te dire quoi ou comment
Je serais étonné que rsync ne préoccupe des alias, il doit les copier comme n'importe quel autre fichier. Donc le résultat doit être identique à une copie par le Finder.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1jhrm3n.4t6nqu1gm532oN%, (Une Bévue) wrote:
> Ce qui me semble normal. > C'est ce qui est sensé être la force des alias, tu les déplacent et ils > fonctionnent encore.
mouais, je viens juste de le vérifier... j'imaginais, à tort, que lorsque l'alias est copié sur un autre Volume, il se référait la racine de ce Volume ...
donc si le Volume source n'est pas monté l'alias perd le lien...
Le système va essayer de le réparer, comme dans mon exemple plus haut. Il y a plusieurs stratégie qui peuvent être appliquée selon le souhait de l'application qui demande la résolution de l'alias, sauf erreur ça peut aller jusqu'à scanner(*) tout un volume pour retrouver un fichier ayant le même nom et la même date de création.
(*) grâce à la structure de HFS, on peut même sans Spotlight, effectuer de telles recherches extrêmement rapidement même sur un gros disque.
Patrick -- Patrick Stadelmann
In article <1jhrm3n.4t6nqu1gm532oN%unbewusst.sein@google.com.invalid>,
unbewusst.sein@google.com.invalid (Une Bévue) wrote:
> Ce qui me semble normal.
> C'est ce qui est sensé être la force des alias, tu les déplacent et ils
> fonctionnent encore.
mouais, je viens juste de le vérifier...
j'imaginais, à tort, que lorsque l'alias est copié sur un autre Volume,
il se référait la racine de ce Volume ...
donc si le Volume source n'est pas monté l'alias perd le lien...
Le système va essayer de le réparer, comme dans mon exemple plus haut.
Il y a plusieurs stratégie qui peuvent être appliquée selon le souhait
de l'application qui demande la résolution de l'alias, sauf erreur ça
peut aller jusqu'à scanner(*) tout un volume pour retrouver un fichier
ayant le même nom et la même date de création.
(*) grâce à la structure de HFS, on peut même sans Spotlight, effectuer
de telles recherches extrêmement rapidement même sur un gros disque.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jhrm3n.4t6nqu1gm532oN%, (Une Bévue) wrote:
> Ce qui me semble normal. > C'est ce qui est sensé être la force des alias, tu les déplacent et ils > fonctionnent encore.
mouais, je viens juste de le vérifier... j'imaginais, à tort, que lorsque l'alias est copié sur un autre Volume, il se référait la racine de ce Volume ...
donc si le Volume source n'est pas monté l'alias perd le lien...
Le système va essayer de le réparer, comme dans mon exemple plus haut. Il y a plusieurs stratégie qui peuvent être appliquée selon le souhait de l'application qui demande la résolution de l'alias, sauf erreur ça peut aller jusqu'à scanner(*) tout un volume pour retrouver un fichier ayant le même nom et la même date de création.
(*) grâce à la structure de HFS, on peut même sans Spotlight, effectuer de telles recherches extrêmement rapidement même sur un gros disque.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1jhrtbk.6kvstco67o2iN%, (Une Bévue) wrote:
Nicolas Michel wrote:
> Les symlink peuvent être relatifs ou absolus.
oui, ça je me souviens comment faire, il suffit de l'indiquer, par le path, à la création.
> Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce > domaine
Ils peuvent être les deux. En général, dans les alias créés par le Finder, il y a le chemin complet, ce qui permet de localiser la cible si on la remplace par un backup. En effet, la première tentative de localisation se fait en déterminant sur quel volume la cible se trouve, et en utilisant l'ID unique du fichier (donc sans être affecté par le fait que la cible a été renommée et / ou déplacée). Si cela ne fonctionne pas (cas de la restauration d'un backup du fichier, qui aura une ID différente), le système va utiliser le chemin complet, qui fonctionnera dans le cas d'un fichier restaurer.
A chaque résolution, l'alias est mis à jour (nouveau chemin complet s'il a été déplacé et / ou renommé, nouvelle ID si c'est un fichier restaurer) afin d'avoir toujours le maximum de chance de fonctionner.
Il y a aussi une stratégie de recherche relative, c'est ce qui est utilisé dans l'exemple que j'ai donné plus haut.
il y a une TN, obsolète là : <http://developer.apple.com/legacy/mac/library/technotes/tn/tn1188.html>
La doc de l'Alias Manager est toujours en ligne, mais tout n'est plus disponible dans Mac OS X.
In article <1jhrtbk.6kvstco67o2iN%unbewusst.sein@google.com.invalid>,
unbewusst.sein@google.com.invalid (Une Bévue) wrote:
Nicolas Michel <NicolasAlex.Michel.remove@epfl.ch> wrote:
> Les symlink peuvent être relatifs ou absolus.
oui, ça je me souviens comment faire, il suffit de l'indiquer, par le
path, à la création.
> Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce
> domaine
Ils peuvent être les deux. En général, dans les alias créés par le
Finder, il y a le chemin complet, ce qui permet de localiser la cible si
on la remplace par un backup. En effet, la première tentative de
localisation se fait en déterminant sur quel volume la cible se trouve,
et en utilisant l'ID unique du fichier (donc sans être affecté par le
fait que la cible a été renommée et / ou déplacée). Si cela ne
fonctionne pas (cas de la restauration d'un backup du fichier, qui aura
une ID différente), le système va utiliser le chemin complet, qui
fonctionnera dans le cas d'un fichier restaurer.
A chaque résolution, l'alias est mis à jour (nouveau chemin complet s'il
a été déplacé et / ou renommé, nouvelle ID si c'est un fichier
restaurer) afin d'avoir toujours le maximum de chance de fonctionner.
Il y a aussi une stratégie de recherche relative, c'est ce qui est
utilisé dans l'exemple que j'ai donné plus haut.
il y a une TN, obsolète là :
<http://developer.apple.com/legacy/mac/library/technotes/tn/tn1188.html>
La doc de l'Alias Manager est toujours en ligne, mais tout n'est plus
disponible dans Mac OS X.
In article <1jhrtbk.6kvstco67o2iN%, (Une Bévue) wrote:
Nicolas Michel wrote:
> Les symlink peuvent être relatifs ou absolus.
oui, ça je me souviens comment faire, il suffit de l'indiquer, par le path, à la création.
> Les alias, aucune idée, mais à nouveau Patrick est le pro dans ce > domaine
Ils peuvent être les deux. En général, dans les alias créés par le Finder, il y a le chemin complet, ce qui permet de localiser la cible si on la remplace par un backup. En effet, la première tentative de localisation se fait en déterminant sur quel volume la cible se trouve, et en utilisant l'ID unique du fichier (donc sans être affecté par le fait que la cible a été renommée et / ou déplacée). Si cela ne fonctionne pas (cas de la restauration d'un backup du fichier, qui aura une ID différente), le système va utiliser le chemin complet, qui fonctionnera dans le cas d'un fichier restaurer.
A chaque résolution, l'alias est mis à jour (nouveau chemin complet s'il a été déplacé et / ou renommé, nouvelle ID si c'est un fichier restaurer) afin d'avoir toujours le maximum de chance de fonctionner.
Il y a aussi une stratégie de recherche relative, c'est ce qui est utilisé dans l'exemple que j'ai donné plus haut.
il y a une TN, obsolète là : <http://developer.apple.com/legacy/mac/library/technotes/tn/tn1188.html>
La doc de l'Alias Manager est toujours en ligne, mais tout n'est plus disponible dans Mac OS X.
Je serais étonné que rsync ne préoccupe des alias, il doit les copier comme n'importe quel autre fichier. Donc le résultat doit être identique à une copie par le Finder.
ouais, c'est exactement ce qui se passe. -- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Je serais étonné que rsync ne préoccupe des alias, il doit les copier
comme n'importe quel autre fichier. Donc le résultat doit être identique
à une copie par le Finder.
ouais, c'est exactement ce qui se passe.
--
« Sur le plus beau trône du monde,
on n'est jamais assis que sur son cul ! »
(Michel de Montaigne)
Je serais étonné que rsync ne préoccupe des alias, il doit les copier comme n'importe quel autre fichier. Donc le résultat doit être identique à une copie par le Finder.
ouais, c'est exactement ce qui se passe. -- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
unbewusst.sein
Patrick Stadelmann wrote:
Le système va essayer de le réparer, comme dans mon exemple plus haut. Il y a plusieurs stratégie qui peuvent être appliquée selon le souhait de l'application qui demande la résolution de l'alias, sauf erreur ça peut aller jusqu'à scanner(*) tout un volume pour retrouver un fichier ayant le même nom et la même date de création.
(*) grâce à la structure de HFS, on peut même sans Spotlight, effectuer de telles recherches extrêmement rapidement même sur un gros disque.
OK, merci, c'était enfoui dans mes souvenirs.
je viens de faire une expérience infructueuse avec les arguments de rsync
si je fais (dans un script) : /usr/local/bin/rsync -qruAENHX --delete --fileflags --force-change ${SRC} ${DST}
ça roule, maintenant comme j'utilise rsync plusieurs fois dans le script, j'ai voulu "ruser" avec les args en écrivant :
RSYNC_ARGS="-qruAENHX --delete --fileflags --force-change" double quote ou en simple quote : RSYNC_ARGS='-qruAENHX --delete --fileflags --force-change'
puis : /usr/local/bin/rsync ${RSYNC_ARGS} ${SRC} ${DST} ça me donne une erreur : rsync: -qruAENHX --delete --fileflags --force-change: unknown option rsync error: syntax or usage error (code 1) at main.c(1425)
ce que je comprends et que, du coup, rsync ne voit plus qu'un seul argument, c'est ça ? -- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Le système va essayer de le réparer, comme dans mon exemple plus haut.
Il y a plusieurs stratégie qui peuvent être appliquée selon le souhait
de l'application qui demande la résolution de l'alias, sauf erreur ça
peut aller jusqu'à scanner(*) tout un volume pour retrouver un fichier
ayant le même nom et la même date de création.
(*) grâce à la structure de HFS, on peut même sans Spotlight, effectuer
de telles recherches extrêmement rapidement même sur un gros disque.
OK, merci, c'était enfoui dans mes souvenirs.
je viens de faire une expérience infructueuse avec les arguments de
rsync
si je fais (dans un script) :
/usr/local/bin/rsync -qruAENHX --delete --fileflags --force-change
${SRC} ${DST}
ça roule, maintenant comme j'utilise rsync plusieurs fois dans le
script, j'ai voulu "ruser" avec les args en écrivant :
RSYNC_ARGS="-qruAENHX --delete --fileflags --force-change"
double quote ou en simple quote :
RSYNC_ARGS='-qruAENHX --delete --fileflags --force-change'
puis :
/usr/local/bin/rsync ${RSYNC_ARGS} ${SRC} ${DST}
ça me donne une erreur :
rsync: -qruAENHX --delete --fileflags --force-change: unknown option
rsync error: syntax or usage error (code 1) at main.c(1425)
ce que je comprends et que, du coup, rsync ne voit plus qu'un seul
argument, c'est ça ?
--
« Sur le plus beau trône du monde,
on n'est jamais assis que sur son cul ! »
(Michel de Montaigne)
Le système va essayer de le réparer, comme dans mon exemple plus haut. Il y a plusieurs stratégie qui peuvent être appliquée selon le souhait de l'application qui demande la résolution de l'alias, sauf erreur ça peut aller jusqu'à scanner(*) tout un volume pour retrouver un fichier ayant le même nom et la même date de création.
(*) grâce à la structure de HFS, on peut même sans Spotlight, effectuer de telles recherches extrêmement rapidement même sur un gros disque.
OK, merci, c'était enfoui dans mes souvenirs.
je viens de faire une expérience infructueuse avec les arguments de rsync
si je fais (dans un script) : /usr/local/bin/rsync -qruAENHX --delete --fileflags --force-change ${SRC} ${DST}
ça roule, maintenant comme j'utilise rsync plusieurs fois dans le script, j'ai voulu "ruser" avec les args en écrivant :
RSYNC_ARGS="-qruAENHX --delete --fileflags --force-change" double quote ou en simple quote : RSYNC_ARGS='-qruAENHX --delete --fileflags --force-change'
puis : /usr/local/bin/rsync ${RSYNC_ARGS} ${SRC} ${DST} ça me donne une erreur : rsync: -qruAENHX --delete --fileflags --force-change: unknown option rsync error: syntax or usage error (code 1) at main.c(1425)
ce que je comprends et que, du coup, rsync ne voit plus qu'un seul argument, c'est ça ? -- « Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! » (Michel de Montaigne)
