Cela ne leur est pas garanti. Il est possible que /foo/oldPath est un point de montage.
Cela peut cependant être facilement vérifié en exécutant mount | grep 'on /foo/oldPath' Aucune sortie ne doit indiquer que le oldPath répertoire n'est pas un point de montage.
Vous devrez être plus prudent si vous utilisez des répertoires imbriqués, car vous pouvez avoir un point de montage n'importe où.
Je ne sais pas si cela est automatisé, mais il convient de noter que le 3ème champ de mount (séparé par des espaces) est le point de montage pour chaque ligne, donc en utilisant un cut -d ' ' -f 3 pourrait être utilisé pour extraire le chemin (si vous avez besoin de vérifier qu'il ne s'agit pas simplement d'une sous-chaîne d'un autre point de montage, comme /foo/oldPath/nested/mountPoint )
Si vous souhaitez traduire ceci en code C/C++, vous pourrez peut-être utiliser system("mount | grep 'on /foo/oldPath'") , mais je ne jurerai pas par ça. Vous aurez peut-être plus de chance sur StackOverflow pour plus de détails sur la mise en œuvre si vous en avez besoin.
Vous ne devriez pas tenter cela, pour diverses raisons (détaillées dans les autres réponses) :/foo/oldPath peut être lui-même un point de montage, ou un système de fichiers superposé peut être présent et empêcher le déplacement des fichiers. Vous pouvez même rencontrer des montages liés, sur des fichiers uniques, qui causeront également des problèmes lors du renommage des fichiers.
Au lieu d'essayer de déterminer à l'avance si les fichiers peuvent être renommés, vous devriez essayer de les renommer et de traiter les erreurs. rename renverra -1 si une erreur se produit, et errno sera défini sur EXDEV si le changement de nom n'est pas possible en raison de problèmes de montage croisé. Vous pouvez ensuite procéder d'une autre manière (copier et supprimer).
En général, pour déterminer si deux objets du système de fichiers se trouvent sur le même système de fichiers, vous devez exécuter stat dessus et regardez l'identifiant de l'appareil (le st_dev champ en struct stat ). Deux objets de système de fichiers sur le même système de fichiers auront le même identifiant de périphérique.
Notez que lorsque vous exécutez sur overlayfs, vous ne pouvez pas compter sur rename() de répertoires préexistants.
Je pense que vous pouvez généralement ignorer cette possibilité, si vous n'écrivez pas un outil de gestion de fichiers à usage général... Par exemple, un gestionnaire de paquets... auquel cas vous pourriez apparemment ne pas le considérer comme réparable (pour des raisons d'atomicité) et vouloir compter sur le nouveau redirect_dir format des superpositions.
C'est donc plus une note pédante pour vous faire savoir que c'est Linux, nous ne nous conformons pas à POSIX si nous ne le voulons pas, et "garanti" est un mot très fort :).
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
À moins que la fonctionnalité "redirect_dir" ne soit activée, rename(2) sur un répertoire inférieur ou fusionné échouera avec EXDEV.
Overlayfs ne correspond déjà pas aux attentes habituelles d'un système de fichiers Unix dans d'autres détails :
Les objets qui ne sont pas des répertoires (fichiers, liens symboliques, fichiers spéciaux de périphérique, etc.) sont présentés à partir du système de fichiers supérieur ou inférieur, selon le cas. Lorsqu'un fichier du système de fichiers inférieur est accédé d'une manière nécessitant un accès en écriture, comme l'ouverture pour l'accès en écriture, la modification de certaines métadonnées, etc., le fichier est d'abord copié du système de fichiers inférieur vers le système de fichiers supérieur (copy_up)...
L'opération copy_up crée essentiellement un nouveau fichier identique et le déplace vers l'ancien nom. Tous les fichiers ouverts faisant référence à cet inode accéderont aux anciennes données.