Vérifie les droits de tes répertoires car il me semble que les fichiers de FAT32 sont root selon la config de mount
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 !
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.
# Help needed
Posté par rangzen . En réponse au message unison et synchronisation d'une clé USB FAT32 montée sous Linux.. É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.