Як mv-папку в Linux, зберігаючи mtime?


12

Я використовую CentOS 5.5 і хотів би перемістити велику кількість папок в одному томі , зберігаючи їх mtime.

Найкраще рішення, яке я міг знайти, таке:

cp -p -r source/data target/
rm -rf source/data

Маючи понад 1 ТБ даних на NFS, копіювання триває назавжди. Я не хочу копіювати. Я хочу миттєвий хід.

Коли я переміщую папку за допомогою mv source/data target/, mtimeпапка (не файли) встановлюється на поточний час. Це відбувається тому, що вміст папки, яку я переміщую, змінюється цією операцією ( ..запис вказує на інший inode).

Я придумав такий сценарій оболонки, який я назвав mv_preserve_mtime.sh:

#!/bin/bash
# Moves source folder to target folder. 
# You are responsible for making sure the target does not exist, otherwise this blows up
export timestamp=`stat -c %y $1`
mv "$1" "$2"
touch --date="${timestamp}" $2

Ну, і це не вийшло. mtimeВідновлюється папка , але всі папки в папці, яку я переміщую (лише ті, що на 1 рівні глибокі), mtimeскидаються через причини, які я не розумію.

У когось є правильне, ефективне та правильне рішення?


Цікаво, чому ваша спроба touchне спрацювала. Це mvкрок чи touchкрок, що змінює mtime підкаталогів? Яка ОС знаходиться на сервері NFS і (якщо ви знаєте), яку тип файлової системи?
Жил 'ТАК - перестань бути злим'

@Gilles: Я не знаю, чому це відбувається. Саме mvкрок викликає неприємності. Сервер NFS - це фактично сховище NetApp, я практично нічого не знаю про його внутрішнє середовище.
Роман Зенка

1
Дякую. Я підозрюю, що це дивацтво NetApp. Інакше touchтреба було попрацювати. До речі, більш портативний спосіб був би touch -r "$1" reference.tmp; mv -- "$1" "$2"; touch -r reference.tmp -- "$2"; rm reference.tmp.
Жил "ТАК - перестань бути злим"

@Gilles: Дуже цікаво, не зрозумів, що statне портативний.
Роман Зенька

Відповіді:


15

POSIX mvне надає жодної можливості запитувати збереження atime / mtime, але оскільки операція локальна на один і той же обсяг, ви можете попросити cpвикористовувати жорсткі посилання замість копіювання даних звичайних файлів за допомогою -lпараметра:

cp -p -r -l source/date target/
rm -rf source/data

Оскільки насправді будуть скопійовані лише каталоги та посилання на файли, це має пройти набагато швидше:

Для отримання додаткової інформації про жорсткі посилання ви можете ознайомитись із відповідною сторінкою Вікіпедії

Що стосується того, чому підкаталоги mtime скидаються з вашим поточним рішенням, це тому, що ви отримуєте та відновлюєте лише батьківський каталог mtime: touch не є рекурсивною командою.


Mtime є складнішим за це. Mtime змінили лише батьківський каталог та каталоги безпосередньо під ним. Усі інші каталоги залишаються незмінними. Можна було б сподіватися, що буде змінено кожен окремий каталог, або лише батьківський.
Роман Зенка

1
Насправді це має сенс: 1) Батьківський каталог має хороший mtime, оскільки він був чітко встановлений на дотик; 2) Записи каталогів, де відтворено з батьківським каталогом, але mtime не було відновлено вручну (структура каталогу Unix та формат inode) 3) Решта структури дерева насправді не була змінена, оскільки ми залишилися на тому самому томі: тому mvнемає "рекурсивної" опції, спуск у підкаталоги робиться лише у випадку, якщо потрібна фактична копія (наприклад, різні томи).
Еврика

@Eureka: Гарне пояснення, але чому це робиться саме так? Якби я повинен був реалізувати mvна каталог data, я б просто змінити ..в dataзмісті «S і змінювати sourceі targetкаталоги в список переміщений елемент правильно. Жодних інших каталогів не потрібно було б чіпати.
Роман Зенка

1
@Roman Zenka Після деякого пошуку ця поведінка виглядає досить слабко визначеною між Unices та файловою системою та залежатиме від основної renameреалізації основної системи syscall ядром та використовуваною файловою системою (системами), NFS додає свою частку проблеми. Є деякі вказівники, що посилаються на подібні невідповідності: patchwork.ozlabs.org/patch/25833 bugs.opensolaris.org/bugdatabase/…
Eureka

@Eureka: Мені надзвичайно важко повірити, що те, що я вважав би таким основним, може бути таким безладом. Це майже 2011. Дякую за ці ресурси!
Роман Зенька

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.