No están garantizados eso. Es posible que /foo/oldPath es un punto de montaje.
Sin embargo, esto se puede comprobar fácilmente ejecutando mount | grep 'on /foo/oldPath' Ninguna salida debe indicar que el oldPath directorio no es un punto de montaje.
Deberá tener más cuidado si utiliza directorios anidados, ya que puede tener un punto de montaje en cualquier lugar.
No estoy seguro de si esto está automatizado, pero vale la pena señalar que el tercer campo desde el montaje (separado por espacios) es el punto de montaje para cada línea, por lo que utilizar un cut -d ' ' -f 3 podría usarse para extraer la ruta (si necesita verificar que no es solo una subcadena de otro punto de montaje, como /foo/oldPath/nested/mountPoint )
Si desea traducir esto a código C/C++, puede usar system("mount | grep 'on /foo/oldPath'") , pero no juraré por eso. Es posible que tenga más suerte en StackOverflow para obtener más detalles de implementación allí si los necesita.
No debe intentar esto, por una variedad de razones (detalladas en las otras respuestas):/foo/oldPath podría ser en sí mismo un punto de montaje, o un sistema de archivos superpuesto podría estar presente y evitar mover archivos. Incluso puede encontrar montajes vinculados, en archivos individuales, lo que también causará problemas al cambiar el nombre de los archivos.
En lugar de tratar de determinar de antemano si los archivos se pueden renombrar, debe intentar renombrarlos y solucionar los errores. rename devolverá -1 si ocurre un error, y errno se establecerá en EXDEV si el cambio de nombre no es posible debido a problemas de montaje cruzado. Luego puede proceder de otra manera (copiar y borrar).
En general, para determinar si dos objetos del sistema de archivos están en el mismo sistema de archivos, debe ejecutar stat en ellos y mire el identificador del dispositivo (el st_dev campo en struct stat ). Dos objetos del sistema de archivos en el mismo sistema de archivos tendrán el mismo identificador de dispositivo.
Tenga en cuenta que cuando ejecuta overlayfs, no puede confiar en rename() de directorios preexistentes.
Creo que normalmente podría ignorar esta posibilidad, si no está escribiendo una herramienta de administración de archivos de propósito general... Por ejemplo, un administrador de paquetes... en cuyo caso aparentemente no lo consideraría reparable (por razones de atomicidad) y desearía confiar en el nuevo redirect_dir formato de overlayfs.
Así que esto es más una nota pedante para hacerle saber que esto es Linux, no cumplimos con POSIX si no queremos, y "garantizado" es una palabra muy fuerte :).
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
A menos que la función "redirect_dir" esté habilitada, cambiar el nombre (2) en un directorio inferior o fusionado fallará con EXDEV.
Overlayfs ya no coincide con las expectativas habituales de un sistema de archivos Unix en otros detalles:
Los objetos que no son directorios (archivos, enlaces simbólicos, archivos especiales de dispositivo, etc.) se presentan desde el sistema de archivos superior o inferior, según corresponda. Cuando se accede a un archivo en el sistema de archivos inferior de una manera que requiere acceso de escritura, como abrir para acceso de escritura, cambiar algunos metadatos, etc., el archivo se copia primero del sistema de archivos inferior al sistema de archivos superior (copiar)...
La operación copy_up esencialmente crea un archivo nuevo e idéntico y lo traslada al nombre anterior. Cualquier archivo abierto que haga referencia a este inodo accederá a los datos antiguos.