En Unix, renombrar un archivo y moverlo a otro directorio son exactamente la misma cosa desde el punto de vista del sistema de archivos. No existe un comando “renombrar” separado porque no hace falta: mv cubre los dos casos con la misma llamada al kernel.
Cuando ejecutas mv informe.txt informe_final.txt, el kernel no copia ni toca el contenido del archivo. Llama a rename(), una syscall que simplemente actualiza la entrada en el directorio: cambia el nombre con el que ese inodo aparece listado. El inodo —la estructura interna que contiene los metadatos y apunta a los bloques de datos reales— ni se mueve ni se modifica. Es una operación atómica: o sucede completamente o no sucede. Esto tiene una implicación práctica importante: rename() solo funciona dentro del mismo filesystem. Si origen y destino están en particiones distintas (por ejemplo, /home y /var montados por separado, o un disco USB), el kernel rechaza la llamada y mv tiene que recurrir al plan B: copiar el archivo byte a byte al destino y luego borrar el original. Eso ya no es atómico, consume espacio en el destino, y puede fallar a mitad si el disco de destino está lleno —dejándote con una copia incompleta y el original ya borrado si el error llega tarde.
Úsalo siempre que necesites reorganizar archivos: renombrar, cambiar de directorio, o las dos cosas a la vez. El único momento en que debes pensártelo dos veces es al mover archivos grandes entre filesystems distintos: asegúrate de que hay espacio suficiente antes.
Lo que se rompe si no tienes cuidado: mv sobrescribe el destino sin preguntar por defecto. Si ya existe informe_final.txt y ejecutas mv informe.txt informe_final.txt, el segundo archivo desaparece sin aviso ni papelera. No hay deshacer.
# Estructura de partida para el ejemplo mkdir -p ~/proyecto/docs ~/proyecto/archivo_2024 touch ~/proyecto/docs/borrador.txt touch ~/proyecto/docs/notas_viejas.txt touch ~/proyecto/docs/config_backup.txt # 1. Renombrar en el mismo directorio (rename() puro, sin tocar datos) mv ~/proyecto/docs/borrador.txt ~/proyecto/docs/borrador_v1.txt # 2. Mover a otro directorio dentro del mismo filesystem mv ~/proyecto/docs/borrador_v1.txt ~/proyecto/archivo_2024/ # 3. Mover y renombrar en una sola operación mv ~/proyecto/docs/config_backup.txt ~/proyecto/archivo_2024/config_2024.txt # 4. Modo interactivo: pregunta antes de sobrescribir # Crea un conflicto a propósito para ver el comportamiento touch ~/proyecto/archivo_2024/notas_viejas.txt # ya existe en destino mv -i ~/proyecto/docs/notas_viejas.txt ~/proyecto/archivo_2024/ # El shell pregunta: overwrite '~/proyecto/archivo_2024/notas_viejas.txt'? (y/n) # 5. Mover en batch: todos los .txt del directorio actual a archivo_2024 # La shell expande *.txt antes de pasárselo a mv cd ~/proyecto/docs touch sesion1.txt sesion2.txt sesion3.txt mv *.txt ~/proyecto/archivo_2024/ # 6. Verificar resultado ls ~/proyecto/docs/ # debe estar vacío ls ~/proyecto/archivo_2024/ # 7. Lo que NO es una papelera: # mv archivo /tmp/papelera/ mueve el archivo, pero /tmp se borra al reiniciar # y no hay ningún mecanismo de restauración. Es solo otro directorio. mkdir -p /tmp/papelera touch ~/proyecto/importante.txt mv ~/proyecto/importante.txt /tmp/papelera/ # El archivo está en /tmp/papelera/importante.txt — y seguirá ahí hasta que # alguien lo borre o el sistema reinicie. No hay "restore".
Lo que acaba de pasar línea a línea
En el paso 1, mv borrador.txt borrador_v1.txt no mueve nada en disco. El kernel actualiza una entrada en el directorio docs/: donde antes ponía borrador.txt ahora pone borrador_v1.txt. El inodo 相mismo, los bloques de datos —los mismos, sin tocar.
En el paso 2, mv borrador_v1.txt ~/proyecto/archivo_2024/ también es una sola llamada rename() porque tanto docs/ como archivo_2024/ están bajo ~/proyecto, que en un sistema de escritorio típico vive todo en la misma partición. El nombre desaparece de un directorio y aparece en el otro. Instantáneo.
En el paso 3 combinamos los dos casos: el archivo cambia de nombre y de directorio en una sola operación. Desde el punto de vista del kernel sigue siendo un único rename().
El paso 4 muestra -i (interactive). Sin esta opción, si el destino ya existe, mv lo pisa sin decir nada. Con -i te pregunta. Puedes hacer este comportamiento permanente con alias mv='mv -i' en tu .bashrc, aunque en scripts eso sería un error: los scripts no cargan aliases, pero es fácil olvidarlo y quemarse.
En el paso 5, fíjate en que mv *.txt ~/proyecto/archivo_2024/ no es magia de mv: es la shell quien expande *.txt en una lista de argumentos antes de ejecutar el comando. mv recibe múltiples archivos de origen y un directorio de destino. Cuando el último argumento es un directorio existente, mueve todos los anteriores dentro de él. Si por error el destino no existiera y hubiera exactamente dos argumentos, mv renombraría el primero con el nombre del segundo —un error clásico.
El paso 7 deja claro que mv archivo /tmp/papelera/ no es equivalente a mandar algo a la papelera del escritorio. La papelera de GNOME o KDE sigue un protocolo (XDG Trash) que guarda metadatos sobre el origen para poder restaurar. Mover a /tmp/papelera/ es solo eso: mover. Si necesitas algo recuperable, usa la papelera del sistema (gio trash archivo) o haz una copia antes.
N° 21