bonsoir.
J'avais déjà posé la question, mais je n'ai pas eu (vu?) de réponse.
Peut-on "délocaliser" un dossier Utilisateur entier sur un autre disque
que le disque interne contenant le reste de l'OS ?
Un simple alias suffit-il ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michael
J'avais déjà posé la question, mais je n'ai pas eu (vu?) de réponse. Peut-on "délocaliser" un dossier Utilisateur entier sur un autre disque que le disque interne contenant le reste de l'OS ?
Oui, mais manip à faire avec beaucoup de précaution :
J'avais déjà posé la question, mais je n'ai pas eu (vu?) de réponse.
Peut-on "délocaliser" un dossier Utilisateur entier sur un autre disque
que le disque interne contenant le reste de l'OS ?
Oui, mais manip à faire avec beaucoup de précaution :
J'avais déjà posé la question, mais je n'ai pas eu (vu?) de réponse. Peut-on "délocaliser" un dossier Utilisateur entier sur un autre disque que le disque interne contenant le reste de l'OS ?
Oui, mais manip à faire avec beaucoup de précaution :
Oui, mais manip à faire avec beaucoup de précaution :
Un lien symbolique vers le dossier sur le second disque aura le même effet.
Mais l'une et l'autre manip risquent de te laisser sur le carreau, le jour où le système décidera de monter le second disque dans /Volumes/Data-1 au lieu de /Volumes/Data Ca arrive, et pas si rarement que ça : il suffit que pour une raison où une autre, le dossier /Volumes/Data, qui est le point de montage du disque Data ne soit pas effacé au redémarrage.
La seule solution fiable à 100% est d'utiliser fstab et l'UUID du disque, mais je ne sais pas si ça marche encore sous Lion.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Michael <berengue.michael@NOPorange.frNOP> wrote:
Oui, mais manip à faire avec beaucoup de précaution :
Un lien symbolique vers le dossier sur le second disque aura le même
effet.
Mais l'une et l'autre manip risquent de te laisser sur le carreau, le
jour où le système décidera de monter le second disque dans
/Volumes/Data-1 au lieu de /Volumes/Data Ca arrive, et pas si rarement
que ça : il suffit que pour une raison où une autre, le dossier
/Volumes/Data, qui est le point de montage du disque Data ne soit pas
effacé au redémarrage.
La seule solution fiable à 100% est d'utiliser fstab et l'UUID du
disque, mais je ne sais pas si ça marche encore sous Lion.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Oui, mais manip à faire avec beaucoup de précaution :
Un lien symbolique vers le dossier sur le second disque aura le même effet.
Mais l'une et l'autre manip risquent de te laisser sur le carreau, le jour où le système décidera de monter le second disque dans /Volumes/Data-1 au lieu de /Volumes/Data Ca arrive, et pas si rarement que ça : il suffit que pour une raison où une autre, le dossier /Volumes/Data, qui est le point de montage du disque Data ne soit pas effacé au redémarrage.
La seule solution fiable à 100% est d'utiliser fstab et l'UUID du disque, mais je ne sais pas si ça marche encore sous Lion.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
usenet
Xavier wrote:
La seule solution fiable à 100% est d'utiliser fstab et l'UUID du disque, mais je ne sais pas si ça marche encore sous Lion.
Et en changeant l'emplacement du dossier utilisateur dans les préférences utilisateur (options avancées, crtl-click sur l'icone de l'utilisateur), cela ne marche pas?
-- Florian Alle Wahrheit durchläuft drei Stufen. Zuerst wird sie lächerlich gemacht oder verzerrt. Dann wird sie bekämpft. Und schließlich wird sie als selbstverständlich angenommen. - Arthur Schopenhauer
Xavier <xavier@groumpf.org> wrote:
La seule solution fiable à 100% est d'utiliser fstab et l'UUID du
disque, mais je ne sais pas si ça marche encore sous Lion.
Et en changeant l'emplacement du dossier utilisateur dans les
préférences utilisateur (options avancées, crtl-click sur l'icone de
l'utilisateur), cela ne marche pas?
--
Florian
Alle Wahrheit durchläuft drei Stufen. Zuerst wird sie lächerlich
gemacht oder verzerrt. Dann wird sie bekämpft. Und schließlich wird
sie als selbstverständlich angenommen. - Arthur Schopenhauer
La seule solution fiable à 100% est d'utiliser fstab et l'UUID du disque, mais je ne sais pas si ça marche encore sous Lion.
Et en changeant l'emplacement du dossier utilisateur dans les préférences utilisateur (options avancées, crtl-click sur l'icone de l'utilisateur), cela ne marche pas?
-- Florian Alle Wahrheit durchläuft drei Stufen. Zuerst wird sie lächerlich gemacht oder verzerrt. Dann wird sie bekämpft. Und schließlich wird sie als selbstverständlich angenommen. - Arthur Schopenhauer
Matt
On Dim 13 novembre 2011, 22:19, Florian wrote:
Et en changeant l'emplacement du dossier utilisateur dans les préférences utilisateur (options avancées, crtl-click sur l'icone de l'utilisateur), cela ne marche pas?
Si c'est sur un autre disque, non. Car il faut être sûr que ce disque soit identifié de manière unique (soit via fstab(5) ou directement dans l'OD).
-- echo '' | tr '[a-z]' '[n-za-m]'
On Dim 13 novembre 2011, 22:19,
Florian <usenet@nachon.net> wrote:
Et en changeant l'emplacement du dossier utilisateur dans les
préférences utilisateur (options avancées, crtl-click sur l'icone de
l'utilisateur), cela ne marche pas?
Si c'est sur un autre disque, non.
Car il faut être sûr que ce disque soit identifié de manière unique
(soit via fstab(5) ou directement dans l'OD).
Et en changeant l'emplacement du dossier utilisateur dans les préférences utilisateur (options avancées, crtl-click sur l'icone de l'utilisateur), cela ne marche pas?
Si c'est sur un autre disque, non. Car il faut être sûr que ce disque soit identifié de manière unique (soit via fstab(5) ou directement dans l'OD).
-- echo '' | tr '[a-z]' '[n-za-m]'
Patrick Stadelmann
In article <j9pi4t$2kmj$, Matt wrote:
On Dim 13 novembre 2011, 22:19, Florian wrote:
> Et en changeant l'emplacement du dossier utilisateur dans les > préférences utilisateur (options avancées, crtl-click sur l'icone de > l'utilisateur), cela ne marche pas?
Si c'est sur un autre disque, non. Car il faut être sûr que ce disque soit identifié de manière unique (soit via fstab(5) ou directement dans l'OD).
Il me semble que Mac OS X, depuis quelques versions, effaces les dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis remonter le volume contenant le dossier de l'utilisateur sans redémarrer, le problème ne devrait jamais se poser.
Patrick -- Patrick Stadelmann
In article <j9pi4t$2kmj$2@talisker.lacave.net>,
Matt <hfrarg@syrius.org.invalid> wrote:
On Dim 13 novembre 2011, 22:19,
Florian <usenet@nachon.net> wrote:
> Et en changeant l'emplacement du dossier utilisateur dans les
> préférences utilisateur (options avancées, crtl-click sur l'icone de
> l'utilisateur), cela ne marche pas?
Si c'est sur un autre disque, non.
Car il faut être sûr que ce disque soit identifié de manière unique
(soit via fstab(5) ou directement dans l'OD).
Il me semble que Mac OS X, depuis quelques versions, effaces les
dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis
remonter le volume contenant le dossier de l'utilisateur sans
redémarrer, le problème ne devrait jamais se poser.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
> Et en changeant l'emplacement du dossier utilisateur dans les > préférences utilisateur (options avancées, crtl-click sur l'icone de > l'utilisateur), cela ne marche pas?
Si c'est sur un autre disque, non. Car il faut être sûr que ce disque soit identifié de manière unique (soit via fstab(5) ou directement dans l'OD).
Il me semble que Mac OS X, depuis quelques versions, effaces les dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis remonter le volume contenant le dossier de l'utilisateur sans redémarrer, le problème ne devrait jamais se poser.
Patrick -- Patrick Stadelmann
Matt
On Lun 14 novembre 2011, 08:13, Patrick Stadelmann wrote:
Il me semble que Mac OS X, depuis quelques versions, effaces les dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis remonter le volume contenant le dossier de l'utilisateur sans redémarrer, le problème ne devrait jamais se poser.
Si le disque est interne et si le nombre de volumes présents au démarrage est toujours le même oui mais si celui-ci est externe, diskarbitrationd(8) lui attribuera une entrée dans /dev qui ne sera pas toujours la même.
Ce qui peut être /dev/disk1-2-3-etc. suivant le nombre de volumes déjà présents. Sans d'UUID et un point de montage défini, il sera impossible de savoir sur quelle entrée le point de montage est.
-- echo '' | tr '[a-z]' '[n-za-m]'
On Lun 14 novembre 2011, 08:13,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Il me semble que Mac OS X, depuis quelques versions, effaces les
dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis
remonter le volume contenant le dossier de l'utilisateur sans
redémarrer, le problème ne devrait jamais se poser.
Si le disque est interne et si le nombre de volumes présents au
démarrage est toujours le même oui mais si celui-ci est externe,
diskarbitrationd(8) lui attribuera une entrée dans /dev qui ne sera pas
toujours la même.
Ce qui peut être /dev/disk1-2-3-etc. suivant le nombre de volumes déjà
présents. Sans d'UUID et un point de montage défini, il sera impossible
de savoir sur quelle entrée le point de montage est.
On Lun 14 novembre 2011, 08:13, Patrick Stadelmann wrote:
Il me semble que Mac OS X, depuis quelques versions, effaces les dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis remonter le volume contenant le dossier de l'utilisateur sans redémarrer, le problème ne devrait jamais se poser.
Si le disque est interne et si le nombre de volumes présents au démarrage est toujours le même oui mais si celui-ci est externe, diskarbitrationd(8) lui attribuera une entrée dans /dev qui ne sera pas toujours la même.
Ce qui peut être /dev/disk1-2-3-etc. suivant le nombre de volumes déjà présents. Sans d'UUID et un point de montage défini, il sera impossible de savoir sur quelle entrée le point de montage est.
-- echo '' | tr '[a-z]' '[n-za-m]'
Patrick Stadelmann
In article <j9qm91$1jkt$, Matt wrote:
On Lun 14 novembre 2011, 08:13, Patrick Stadelmann wrote:
> Il me semble que Mac OS X, depuis quelques versions, effaces les > dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis > remonter le volume contenant le dossier de l'utilisateur sans > redémarrer, le problème ne devrait jamais se poser.
Si le disque est interne et si le nombre de volumes présents au démarrage est toujours le même oui mais si celui-ci est externe, diskarbitrationd(8) lui attribuera une entrée dans /dev qui ne sera pas toujours la même.
L'entrée dans /dev change aussi pour les disques internes, y compris pour le disque de démarrage.
Ce qui peut être /dev/disk1-2-3-etc. suivant le nombre de volumes déjà présents. Sans d'UUID et un point de montage défini, il sera impossible de savoir sur quelle entrée le point de montage est.
Le lien symbolique utilise le nom du volume, il est donc indépendant de l'identifiant dans /dev.
Je n'ai pas délocalisé pour dossier, mais j'ai des liens symboliques vers d'autres volumes, et bien que je redémarre ma machine tous les jours, je n'ai jamais eu de problème lié à un changement du point de montage genre /Volumes/MonVolume-1 depuis en tout cas Leopard (mais en effet ça pouvait arriver avant, en cas de démontage sauvage).
Patrick -- Patrick Stadelmann
In article <j9qm91$1jkt$2@talisker.lacave.net>,
Matt <hfrarg@syrius.org.invalid> wrote:
On Lun 14 novembre 2011, 08:13,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Il me semble que Mac OS X, depuis quelques versions, effaces les
> dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis
> remonter le volume contenant le dossier de l'utilisateur sans
> redémarrer, le problème ne devrait jamais se poser.
Si le disque est interne et si le nombre de volumes présents au
démarrage est toujours le même oui mais si celui-ci est externe,
diskarbitrationd(8) lui attribuera une entrée dans /dev qui ne sera pas
toujours la même.
L'entrée dans /dev change aussi pour les disques internes, y compris
pour le disque de démarrage.
Ce qui peut être /dev/disk1-2-3-etc. suivant le nombre de volumes déjà
présents. Sans d'UUID et un point de montage défini, il sera impossible
de savoir sur quelle entrée le point de montage est.
Le lien symbolique utilise le nom du volume, il est donc indépendant de
l'identifiant dans /dev.
Je n'ai pas délocalisé pour dossier, mais j'ai des liens symboliques
vers d'autres volumes, et bien que je redémarre ma machine tous les
jours, je n'ai jamais eu de problème lié à un changement du point de
montage genre /Volumes/MonVolume-1 depuis en tout cas Leopard (mais en
effet ça pouvait arriver avant, en cas de démontage sauvage).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
On Lun 14 novembre 2011, 08:13, Patrick Stadelmann wrote:
> Il me semble que Mac OS X, depuis quelques versions, effaces les > dossiers vides dans /Volumes au démarrage. Donc à moins de démonter puis > remonter le volume contenant le dossier de l'utilisateur sans > redémarrer, le problème ne devrait jamais se poser.
Si le disque est interne et si le nombre de volumes présents au démarrage est toujours le même oui mais si celui-ci est externe, diskarbitrationd(8) lui attribuera une entrée dans /dev qui ne sera pas toujours la même.
L'entrée dans /dev change aussi pour les disques internes, y compris pour le disque de démarrage.
Ce qui peut être /dev/disk1-2-3-etc. suivant le nombre de volumes déjà présents. Sans d'UUID et un point de montage défini, il sera impossible de savoir sur quelle entrée le point de montage est.
Le lien symbolique utilise le nom du volume, il est donc indépendant de l'identifiant dans /dev.
Je n'ai pas délocalisé pour dossier, mais j'ai des liens symboliques vers d'autres volumes, et bien que je redémarre ma machine tous les jours, je n'ai jamais eu de problème lié à un changement du point de montage genre /Volumes/MonVolume-1 depuis en tout cas Leopard (mais en effet ça pouvait arriver avant, en cas de démontage sauvage).
Patrick -- Patrick Stadelmann
Matt
On Lun 14 novembre 2011, 10:29, Patrick Stadelmann wrote:
L'entrée dans /dev change aussi pour les disques internes, y compris pour le disque de démarrage.
Oui aussi j'ai mollé (faut dire que je ne redémarre plus souvent).
Le lien symbolique utilise le nom du volume, il est donc indépendant de l'identifiant dans /dev.
Je n'ai pas délocalisé pour dossier, mais j'ai des liens symboliques vers d'autres volumes, et bien que je redémarre ma machine tous les jours, je n'ai jamais eu de problème lié à un changement du point de montage genre /Volumes/MonVolume-1 depuis en tout cas Leopard (mais en effet ça pouvait arriver avant, en cas de démontage sauvage).
C'est une des causes possible en effet. Il est donc plus prudent de « verrouiller » en attribuant un UUID au disque, surtout pour une situation sensible comme celle qui nous intéresse.
-- echo '' | tr '[a-z]' '[n-za-m]'
On Lun 14 novembre 2011, 10:29,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
L'entrée dans /dev change aussi pour les disques internes, y compris
pour le disque de démarrage.
Oui aussi j'ai mollé (faut dire que je ne redémarre plus souvent).
Le lien symbolique utilise le nom du volume, il est donc indépendant de
l'identifiant dans /dev.
Je n'ai pas délocalisé pour dossier, mais j'ai des liens symboliques
vers d'autres volumes, et bien que je redémarre ma machine tous les
jours, je n'ai jamais eu de problème lié à un changement du point de
montage genre /Volumes/MonVolume-1 depuis en tout cas Leopard (mais en
effet ça pouvait arriver avant, en cas de démontage sauvage).
C'est une des causes possible en effet.
Il est donc plus prudent de « verrouiller » en attribuant un UUID au
disque, surtout pour une situation sensible comme celle qui nous
intéresse.
On Lun 14 novembre 2011, 10:29, Patrick Stadelmann wrote:
L'entrée dans /dev change aussi pour les disques internes, y compris pour le disque de démarrage.
Oui aussi j'ai mollé (faut dire que je ne redémarre plus souvent).
Le lien symbolique utilise le nom du volume, il est donc indépendant de l'identifiant dans /dev.
Je n'ai pas délocalisé pour dossier, mais j'ai des liens symboliques vers d'autres volumes, et bien que je redémarre ma machine tous les jours, je n'ai jamais eu de problème lié à un changement du point de montage genre /Volumes/MonVolume-1 depuis en tout cas Leopard (mais en effet ça pouvait arriver avant, en cas de démontage sauvage).
C'est une des causes possible en effet. Il est donc plus prudent de « verrouiller » en attribuant un UUID au disque, surtout pour une situation sensible comme celle qui nous intéresse.
