J'ai RTFMé, Googlé dans tous les sens, sans aucun succès.
Voilà mon souci: Unison a l'air plutôt sympathique pour synchroniser des répertoires. Tant mieux, j'ai une clé USB que j'utilise pour transporter des données entre le boulot et chez moi, et il m'arrive de modifier dessus des fichiers, aussi bien au boulot que chez moi. Je voudrais donc synchroniser tout ça.
Or lorsque j'essaie, je tombe sur un os. Une fois ma clé USB montée, je lance Unison, qui détecte bien les changements à opérer. Je lui dit GO (pour faire la synchro) et là, c'est le drame:
bidule.ext
Error in setting permissions:
Operation not permitted [chmod(/mnt/removable/.#bidule.ext.0.unison.tmp)]
Horreur malheur ! Ma clé est bien entendu en fat(32), au boulot il n'y a que Windows. Et cette andouille d'unisson veut absolument (même avec l'option "-perm 0") faire joujou avec les permissions sur ma clé USB tout en fat (d'où le hic !).
Donc pas de synchro...
Est-ce que quelqu'un a rencontré et résolu ce problème ?
Sinon, quelqu'un peut me proposer quelque chose pour synchroniser ma clé USB (fat) avec mes fichiers (dans mon /home, ext3) ?
# Help needed
Posté par rangzen (site web personnel) . Évalué à 3.
Je fais toutes mes synchro en root (bouuuuuhhhhhh) puis je passe un chown user:group -R rep_maj
C'est con mais je synchronise plusieurs PC surlesquels je n'ai pas le même UID ou GID.
Vive unison ! Encore un exemple que l'innovation n'a rien à voir avec les brevets !
sinon :
http://www.cis.upenn.edu/~bcpierce/unison/download/stable/latest/un(...)
Permissions
Synchronizing the permission bits of files is slightly tricky when two different filesytems are involved (e.g., when synchronizing a Windows client and a Unix server). In detail, here's how it works:
* When the permission bits of an existing file or directory are changed, the values of those bits that make sense on both operating systems will be propagated to the other replica. The other bits will not be changed.
* When a newly created file is propagated to a remote replica, the permission bits that make sense in both operating systems are also propagated. The values of the other bits are set to default values (they are taken from the current umask, if the receiving host is a Unix system).
* For security reasons, the Unix setuid and setgid bits are not propagated.
* The Unix owner and group ids are not propagated. (What would this mean, in general?) All files are created with the owner and group of the server process.
Cross-Platform Synchronization
If you use Unison to synchronize files between Windows and Unix systems, there are a few special issues to be aware of.
Case conflicts. In Unix, filenames are case sensitive: foo and FOO can refer to different files. In Windows, on the other hand, filenames are not case sensitive: foo and FOO can only refer to the same file. This means that a Unix foo and FOO cannot be synchronized onto a Windows system --- Windows won't allow two different files to have the ``same'' name. Unison detects this situation for you, and reports that it cannot synchronize the files.
You can deal with a case conflict in a couple of ways. If you need to have both files on the Windows system, your only choice is to rename one of the Unix files to avoid the case conflict, and re-synchronize. If you don't need the files on the Windows system, you can simply disregard Unison's warning message, and go ahead with the synchronization; Unison won't touch those files. If you don't want to see the warning on each synchronization, you can tell Unison to ignore the files (see the Ignore section).
Illegal filenames. Unix allows some filenames that are illegal in Windows. For example, colons (`:') are not allowed in Windows filenames, but they are legal in Unix filenames. This means that a Unix file foo:bar can't be synchronized to a Windows system. As with case conflicts, Unison detects this situation for you, and you have the same options: you can either rename the Unix file and re-synchronize, or you can ignore it.
[^] # Re: Help needed
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Mais, on peut spécifier un autre utilisateur avec l'option uid (mount -o uid=1000 ...).
On peut aussi rajouter la ligne suivante dans /etc/fstab :
/dev/sda1 /mnt/removable vfat user,rw,noauto 0 0
aisi, tout utilisateur pourra monter la clé usb, et les fichiers montés appartiendront à l'utilisateur qui a monté la clé usb.
[^] # Re: Help needed
Posté par Beurt . Évalué à 2.
Par ailleurs, j'ai déjà les droits en écriture sur le disque monté (monté avec l'option "user" comme le propose NoNo plus bas). Le problème c'est que quand unison essaie de changer les droits, il récolte fatalement une erreur (car le filesystem ne gère aucun droit)...
Le problème n'est donc pas là et la solution, je le crains, bien plus complexe !
[^] # Re: Help needed
Posté par David PARDESSUS . Évalué à 2.
Et la manip de NoNo a bien marche sur ma mdk 10.1
Avant
/dev/sda1 /mnt/removable auto umask=0,user,iocharset=iso8859-15,sync,kudzu,codepage=850,noauto,exec,users 0 0
Apres
/dev/sda1 /mnt/removable vfat user,rw,noauto 0 0
et plus d'erreur de chmod !
[^] # Re: Help needed
Posté par Beurt . Évalué à 1.
Celà fonctionne effectivement très bien.
C'est sans doute l'option auto ou autre qui posait problème.
Merci !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.