C'est une réponse très tardive, mais... oui rename() est atomique mais pas dans le sens de votre question. Sous Linux, rename(2) dit :
Cependant, lors de l'écrasement, il y aura probablement une fenêtre dans laquelle oldpath et newpath font référence au fichier renommé.
Mais rename() est toujours atomique dans un sens très important :si vous l'utilisez pour écraser un fichier, vous vous retrouverez avec l'ancienne ou la nouvelle version et rien d'autre.
[mise à jour : mais comme @jonas-wielicki le souligne dans les commentaires, vous devez vous assurer que le fichier que vous renommez a bien un contenu à jour, en utilisant fsync() et amis.]
Si newpath existe déjà, il sera remplacé de manière atomique (sous réserve de quelques conditions ; voir ERREURS ci-dessous), de sorte qu'il n'y a aucun moment où un autre processus tentant d'accéder à newpath le trouvera manquant.
Si vous voyez des ERREURS, vous constaterez que le changement de nom peut échouer, mais cela ne brisera jamais l'atomicité.
Tout cela provient de la page de manuel Linux. Ce que je ne sais pas, c'est si vous faites un rename() sur un système de fichiers réseau où le serveur exécute un système d'exploitation différent. Le client a-t-il alors l'espoir de garantir l'atomicité ? J'en doute.
Oui et non.
rename() est atomique en supposant que le système d'exploitation ne plante pas. Il ne peut pas être divisé par une autre opération de système de fichiers.
Si le système plante, vous verrez peut-être une opération ln() à la place.
Notez également que lorsque vous travaillez sur un système de fichiers réseau, vous pouvez obtenir ENOENT lorsque l'opération a réussi. Le système de fichiers local ne peut pas vous faire ça.
Je ne suis pas sûr que la partie "essentiellement" de votre question soit valable. À moins que vous n'ayez une sorte de synchronisation entre les deux, le renommage atomique n'a pas d'importance. Si la copie du répertoire arrive avant le renommage, vous allez avoir file1 aux deux endroits.
Je ne sais pas si vous vouliez dire thread ou processus, mais s'il existe des mécanismes de verrouillage pour les deux, les verrous de thread sont de loin les plus simples car ils n'ont pas à franchir les limites des processus.