Bonsoir,
Je possède un bipro 1.25 avec OS 10.3.3, lorsque je monte un volume réseau
sur le bureau (Snap ou dossier MacLan) quand le mac se met en veille, à son
réveille les dossier ne sont plus disponibles et quitte de façon "inopinés".
Pour info, je suis en TCP/IP avec adresse fixe.
Je possède un bipro 1.25 avec OS 10.3.3, lorsque je monte un volume réseau sur le bureau (Snap ou dossier MacLan) quand le mac se met en veille, à son réveille les dossier ne sont plus disponibles et quitte de façon "inopinés".
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en non-veille comme cela a pu être le cas.
Pour info, je suis en TCP/IP avec adresse fixe.
Aucune relation avec le pb
Y-a-t'il une solution ?
Ne pas mettre en veille, mettre en veille uniquement l'écran.
-- Jacques PERROCHEAU ______________________________________________________________ e-mail: mailto:
FG <nopub.atelier@online.fr> wrote:
Je possède un bipro 1.25 avec OS 10.3.3, lorsque je monte un volume réseau
sur le bureau (Snap ou dossier MacLan) quand le mac se met en veille, à son
réveille les dossier ne sont plus disponibles et quitte de façon "inopinés".
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation
de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en
non-veille comme cela a pu être le cas.
Pour info, je suis en TCP/IP avec adresse fixe.
Aucune relation avec le pb
Y-a-t'il une solution ?
Ne pas mettre en veille, mettre en veille uniquement l'écran.
--
Jacques PERROCHEAU
______________________________________________________________
e-mail: mailto:jperrocheau@mac.com
Je possède un bipro 1.25 avec OS 10.3.3, lorsque je monte un volume réseau sur le bureau (Snap ou dossier MacLan) quand le mac se met en veille, à son réveille les dossier ne sont plus disponibles et quitte de façon "inopinés".
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en non-veille comme cela a pu être le cas.
Pour info, je suis en TCP/IP avec adresse fixe.
Aucune relation avec le pb
Y-a-t'il une solution ?
Ne pas mettre en veille, mettre en veille uniquement l'écran.
-- Jacques PERROCHEAU ______________________________________________________________ e-mail: mailto:
laurent.pertois
Jacques Perrocheau wrote:
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en non-veille comme cela a pu être le cas.
Oui, mais normalement en sortie de veille le système tente une reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter. C'est d'ailleurs désagréable quand on oublie de démonter un volume avant de partir d'un lieu avec un PB, à la sortie de veille il mouline en quète du serveur.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jacques Perrocheau <jperrocheau@mac.com.invalid> wrote:
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation
de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en
non-veille comme cela a pu être le cas.
Oui, mais normalement en sortie de veille le système tente une
reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers
les volumes pour les faire remonter. C'est d'ailleurs désagréable quand
on oublie de démonter un volume avant de partir d'un lieu avec un PB, à
la sortie de veille il mouline en quète du serveur.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en non-veille comme cela a pu être le cas.
Oui, mais normalement en sortie de veille le système tente une reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter. C'est d'ailleurs désagréable quand on oublie de démonter un volume avant de partir d'un lieu avec un PB, à la sortie de veille il mouline en quète du serveur.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
jperrocheau
Laurent Pertois wrote:
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en non-veille comme cela a pu être le cas.
Oui, mais normalement en sortie de veille le système tente une reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps (par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais verrouiller le Trousseau à la mise en veille.
C'est d'ailleurs désagréable quand on oublie de démonter un volume avant de partir d'un lieu avec un PB, à la sortie de veille il mouline en quète du serveur.
Je vois... ;)
-- Jacques PERROCHEAU ______________________________________________________________ e-mail: mailto:
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation
de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en
non-veille comme cela a pu être le cas.
Oui, mais normalement en sortie de veille le système tente une
reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers
les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps
(par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais
verrouiller le Trousseau à la mise en veille.
C'est d'ailleurs désagréable quand on oublie de démonter un volume avant
de partir d'un lieu avec un PB, à la sortie de veille il mouline en quète
du serveur.
Je vois... ;)
--
Jacques PERROCHEAU
______________________________________________________________
e-mail: mailto:jperrocheau@mac.com
AMHA, comportment normal... puisque que le Mac "éteint" l'alimentation de la "puce Ethernet". Un volume monté ne force plus le Mac à rester en non-veille comme cela a pu être le cas.
Oui, mais normalement en sortie de veille le système tente une reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps (par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais verrouiller le Trousseau à la mise en veille.
C'est d'ailleurs désagréable quand on oublie de démonter un volume avant de partir d'un lieu avec un PB, à la sortie de veille il mouline en quète du serveur.
Je vois... ;)
-- Jacques PERROCHEAU ______________________________________________________________ e-mail: mailto:
Nicolas.MICHEL
FG wrote:
Bonsoir, Je possède un bipro 1.25 avec OS 10.3.3, lorsque je monte un volume réseau sur le bureau (Snap ou dossier MacLan) quand le mac se met en veille, à son réveille les dossier ne sont plus disponibles et quitte de façon "inopinés". Pour info, je suis en TCP/IP avec adresse fixe.
Y-a-t'il une solution ?
Si j'ai suivi ce qu'on dit les autre et que je le compare avec mes (douloureuses) expériences, je dirais que le finder tentera de remonter le partage du réveil mais que le résultat vas dépendre du mode de montage et du mode d'authentificaiton.
- si tu es en "guest" ça devrait remonter sans problèmes - si l'authentification utilises le "kerberos" ça devrait aussi remonter (à vérifier) - si tu as activé le trousseau de clef et que tu as beaucoup de chance, ça peut fonctionner. Chez moi le trousseau fonctionne aléatoirement sur des partages reseau depuis la première version de Mac OS X.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
FG <nopub.atelier@online.fr> wrote:
Bonsoir,
Je possède un bipro 1.25 avec OS 10.3.3, lorsque je monte un volume réseau
sur le bureau (Snap ou dossier MacLan) quand le mac se met en veille, à son
réveille les dossier ne sont plus disponibles et quitte de façon "inopinés".
Pour info, je suis en TCP/IP avec adresse fixe.
Y-a-t'il une solution ?
Si j'ai suivi ce qu'on dit les autre et que je le compare avec mes
(douloureuses) expériences, je dirais que le finder tentera de remonter
le partage du réveil mais que le résultat vas dépendre du mode de
montage et du mode d'authentificaiton.
- si tu es en "guest" ça devrait remonter sans problèmes
- si l'authentification utilises le "kerberos" ça devrait aussi remonter
(à vérifier)
- si tu as activé le trousseau de clef et que tu as beaucoup de chance,
ça peut fonctionner. Chez moi le trousseau fonctionne aléatoirement sur
des partages reseau depuis la première version de Mac OS X.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Bonsoir, Je possède un bipro 1.25 avec OS 10.3.3, lorsque je monte un volume réseau sur le bureau (Snap ou dossier MacLan) quand le mac se met en veille, à son réveille les dossier ne sont plus disponibles et quitte de façon "inopinés". Pour info, je suis en TCP/IP avec adresse fixe.
Y-a-t'il une solution ?
Si j'ai suivi ce qu'on dit les autre et que je le compare avec mes (douloureuses) expériences, je dirais que le finder tentera de remonter le partage du réveil mais que le résultat vas dépendre du mode de montage et du mode d'authentificaiton.
- si tu es en "guest" ça devrait remonter sans problèmes - si l'authentification utilises le "kerberos" ça devrait aussi remonter (à vérifier) - si tu as activé le trousseau de clef et que tu as beaucoup de chance, ça peut fonctionner. Chez moi le trousseau fonctionne aléatoirement sur des partages reseau depuis la première version de Mac OS X.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
laurent.pertois
Jacques Perrocheau wrote:
Oui, mais normalement en sortie de veille le système tente une reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps (par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais verrouiller le Trousseau à la mise en veille.
Il ne m'a rien demandé et mon trousseau est aussi verrouillé à chaque mise en veille.
C'est d'ailleurs désagréable quand on oublie de démonter un volume avant de partir d'un lieu avec un PB, à la sortie de veille il mouline en quète du serveur.
Je vois... ;)
Bon, en 10.3 ça va mieux, il te prévient rapidement que tu n'as plus accès au serveur et te demande si tu souhaites te déconnecter. En 10.2 c'était moulinage avec toutes les applis pendant tout le temps des tentatives de reconnexion.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jacques Perrocheau <jperrocheau@mac.com.invalid> wrote:
Oui, mais normalement en sortie de veille le système tente une
reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers
les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps
(par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais
verrouiller le Trousseau à la mise en veille.
Il ne m'a rien demandé et mon trousseau est aussi verrouillé à chaque
mise en veille.
C'est d'ailleurs désagréable quand on oublie de démonter un volume avant
de partir d'un lieu avec un PB, à la sortie de veille il mouline en quète
du serveur.
Je vois... ;)
Bon, en 10.3 ça va mieux, il te prévient rapidement que tu n'as plus
accès au serveur et te demande si tu souhaites te déconnecter. En 10.2
c'était moulinage avec toutes les applis pendant tout le temps des
tentatives de reconnexion.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Oui, mais normalement en sortie de veille le système tente une reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps (par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais verrouiller le Trousseau à la mise en veille.
Il ne m'a rien demandé et mon trousseau est aussi verrouillé à chaque mise en veille.
C'est d'ailleurs désagréable quand on oublie de démonter un volume avant de partir d'un lieu avec un PB, à la sortie de veille il mouline en quète du serveur.
Je vois... ;)
Bon, en 10.3 ça va mieux, il te prévient rapidement que tu n'as plus accès au serveur et te demande si tu souhaites te déconnecter. En 10.2 c'était moulinage avec toutes les applis pendant tout le temps des tentatives de reconnexion.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jacques Perrocheau
In article <1gchyl0.bm6sag1laznthN%, (Laurent Pertois) wrote:
Oui, mais normalement en sortie de veille le système tente une reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps (par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais verrouiller le Trousseau à la mise en veille.
Il ne m'a rien demandé et mon trousseau est aussi verrouillé à chaque mise en veille.
Humm! tu fais cela entre deux machines sous Mac OS 10.3.3... ?
Je viens de réessayer entre une machine sous Mac OS 10.3.3 (client) et une machine en Mac OS 8.6 (serveur), j'ai bien droit à une déconnexion à la mise en veille de la machine client, quelque soit le réglage du Trousseau.
-- Jacques PERROCHEAU Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510 Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
In article <1gchyl0.bm6sag1laznthN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Oui, mais normalement en sortie de veille le système tente une
reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers
les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps
(par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais
verrouiller le Trousseau à la mise en veille.
Il ne m'a rien demandé et mon trousseau est aussi verrouillé à chaque
mise en veille.
Humm! tu fais cela entre deux machines sous Mac OS 10.3.3... ?
Je viens de réessayer entre une machine sous Mac OS 10.3.3 (client) et
une machine en Mac OS 8.6 (serveur), j'ai bien droit à une déconnexion à
la mise en veille de la machine client, quelque soit le réglage du
Trousseau.
--
Jacques PERROCHEAU
Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510
Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex
Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
In article <1gchyl0.bm6sag1laznthN%, (Laurent Pertois) wrote:
Oui, mais normalement en sortie de veille le système tente une reconnexion (12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter.
Et fait-il cela "smart" même si le Trousseau est verrouillé entre temps (par choix)... ? Perso, j'ai le comportement décrit par FG, car je fais verrouiller le Trousseau à la mise en veille.
Il ne m'a rien demandé et mon trousseau est aussi verrouillé à chaque mise en veille.
Humm! tu fais cela entre deux machines sous Mac OS 10.3.3... ?
Je viens de réessayer entre une machine sous Mac OS 10.3.3 (client) et une machine en Mac OS 8.6 (serveur), j'ai bien droit à une déconnexion à la mise en veille de la machine client, quelque soit le réglage du Trousseau.
-- Jacques PERROCHEAU Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510 Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
laurent.pertois
Jacques Perrocheau wrote:
Humm! tu fais cela entre deux machines sous Mac OS 10.3.3... ?
Voui.
Je viens de réessayer entre une machine sous Mac OS 10.3.3 (client) et une machine en Mac OS 8.6 (serveur), j'ai bien droit à une déconnexion à la mise en veille de la machine client, quelque soit le réglage du Trousseau.
Ah désolé, je n'ai plus ce genre d'antiquités sous la main ;-)
Cela dit, normalement, ça n'a rien à voir avec le serveur si ce n'est que ce dernier voyant disparaître le client peut fermer la connexion, ce que ne fait pas forcément l'AppleFileServer qui laisse un délai pour suspension.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
Humm! tu fais cela entre deux machines sous Mac OS 10.3.3... ?
Voui.
Je viens de réessayer entre une machine sous Mac OS 10.3.3 (client) et
une machine en Mac OS 8.6 (serveur), j'ai bien droit à une déconnexion à
la mise en veille de la machine client, quelque soit le réglage du
Trousseau.
Ah désolé, je n'ai plus ce genre d'antiquités sous la main ;-)
Cela dit, normalement, ça n'a rien à voir avec le serveur si ce n'est
que ce dernier voyant disparaître le client peut fermer la connexion, ce
que ne fait pas forcément l'AppleFileServer qui laisse un délai pour
suspension.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Humm! tu fais cela entre deux machines sous Mac OS 10.3.3... ?
Voui.
Je viens de réessayer entre une machine sous Mac OS 10.3.3 (client) et une machine en Mac OS 8.6 (serveur), j'ai bien droit à une déconnexion à la mise en veille de la machine client, quelque soit le réglage du Trousseau.
Ah désolé, je n'ai plus ce genre d'antiquités sous la main ;-)
Cela dit, normalement, ça n'a rien à voir avec le serveur si ce n'est que ce dernier voyant disparaître le client peut fermer la connexion, ce que ne fait pas forcément l'AppleFileServer qui laisse un délai pour suspension.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
pmanet
Laurent Pertois wrote:
(12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter.
c'est ça ce message qu'on voit dans la console quand un volume distant a été éteint : "same message repeted 14 fois" ou genre ? -- Philippe Manet
(12 fois même, c'est dire s'il est patient et obstiné) vers
les volumes pour les faire remonter.
c'est ça ce message qu'on voit dans la console quand un volume distant a
été éteint : "same message repeted 14 fois" ou genre ?
--
Philippe Manet
pmanet@invivo.edu
(12 fois même, c'est dire s'il est patient et obstiné) vers les volumes pour les faire remonter.
c'est ça ce message qu'on voit dans la console quand un volume distant a été éteint : "same message repeted 14 fois" ou genre ? -- Philippe Manet
laurent.pertois
manet wrote:
c'est ça ce message qu'on voit dans la console quand un volume distant a été éteint : "same message repeted 14 fois" ou genre ?
Normalement, si le volume distant est éteint proprement, il te déconnecte. Mais sinon, oui, c'est certainement ce message.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
manet <pmanet@invivo.edu> wrote:
c'est ça ce message qu'on voit dans la console quand un volume distant a
été éteint : "same message repeted 14 fois" ou genre ?
Normalement, si le volume distant est éteint proprement, il te
déconnecte. Mais sinon, oui, c'est certainement ce message.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
c'est ça ce message qu'on voit dans la console quand un volume distant a été éteint : "same message repeted 14 fois" ou genre ?
Normalement, si le volume distant est éteint proprement, il te déconnecte. Mais sinon, oui, c'est certainement ce message.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
pmanet
Laurent Pertois wrote:
Normalement, si le volume distant est éteint proprement,
le volume distant est généralement du W2k ou du XP, ce qui me semble incompatible avec ce que tu dis. -- Philippe Manet
