Это должно работать:
mkdir pretty_name && tar xf ugly_name.tar -C pretty_name --strip-components 1
-C
изменения в указанном каталоге прежде, чем распаковать (или упаковать). --strip-components
удаляет конкретное количество каталогов от имен файлов, сохраненных в архиве.
Обратите внимание, что это не действительно портативно. Tar GNU и по крайней мере некоторые смолы BSD имеет --strip-components
опция, но, кажется, не существует на других подобных Unix платформах.
Немой способ сделать это работал бы в значительной степени везде все же.
tar xf ugly_name.tar && mv ugly_name pretty_name
/usr
находится на отдельном разделе, поврежденном /usr
не означает, что Вы не можете восстановиться /etc
./
не может всегда быть ro (/root
возможно, должен быть rw и т.д.), но /usr
может. Это может использоваться для создания ro как можно больше./tmp
(не надежный, но быстрый для многих файлов) и /home
(должно быть надежным). Similary /var
содержит данные в то время как /usr
не делает так /usr
устойчивость может быть жертвой, но не так как /tmp
.Отдельное /usr
может быть полезным, если у Вас есть несколько машин, совместно использующих ту же ОС. Они могут совместно использовать центральный сингл /usr
вместо того, чтобы копировать его в каждой системе. /usr
может быть смонтирован только для чтения.
/var
и /tmp
может быть заполнено пользовательскими программами или демонами. Поэтому может быть безопасно иметь их в отдельных разделах, которые предотвратили бы /
, корневой раздел, чтобы быть на 100% полным, и поразил бы Вашу систему плохо. Чтобы постараться не иметь два отличных раздела для них, весьма распространено видеть /tmp
будучи символьной ссылкой на /var/tmp
.
/usr
вполне ограничен затем?
– Alex B
18.08.2010, 15:56
/usr
через NFS к другим системам. Но Вы могли совместно использовать его, даже если это не отдельный раздел, это верно... взгляды вслух... Монтирование действительно ли только для чтения является достаточно хорошей причиной?
– Didier Trosset
18.08.2010, 16:14
/etc
.
– intuited
16.02.2011, 17:44
Поскольку обычные пользователи могут заставить вещи быть записанными в /var
и /tmp
, и таким образом потенциально проблемы причины для целой системы. Таким образом, пользовательские процессы могут заполниться /var
и /tmp
, но не корневая фс отдельное /usr
полезно для /usr
по NFS, или другая удаленная фс.
(Я надеюсь, что это ясно, у меня еще не было кофе),
Проблема - то, что целая корневая фс делает систему Linux недействующей к расширению этого, даже администратор фиксирует ее без восстановления CD или подобный. Когда /tmp
и /var
и в особенности /home
находятся в отдельном разделе, корневая фс не может никогда заполняться без администратора, делающего его. Взять /usr
в соединение, в которое все обычные установки будут помещены, и даже установка нового программного обеспечения, не может вызвать эту проблему.
В целом аргументы в пользу того, чтобы иметь отдельные разделы:
Безопасность: можно, например, смонтировать раздел, только для чтения для хранения злонамеренных пользователей (или процессы) от перезаписи или замены двоичных файлов там с троянцами. Таким образом, если Ваши ssh двоичные жизни в/usr/local/bin и/usr/local смонтированы только для чтения, будет трудным для любого заменить тот двоичный файл.
Гибкость/Удобство: например, если Вы настраиваете / var на его собственном разделе, и это добирается до полных 80%, можно изменить размер его или даже переместить его в другой диск в случае необходимости. Я должен сделать это, чем соглашение с системой, чья '/' на 100% полно, потому что журналы под / var вышли из строя в некотором роде. Различные разделы могут также иметь различные файловые системы полностью, позволяя Вашей ОС использовать ext3 (например), и Вашу базу данных для использования ext4 или объектного репозитория для использования XFS или пользовательского приложения для использования... неструктурированных устройств!
Традиционно, это было сделано этот путь из-за особенностей аппаратных средств DEC, на которых это было разработано. Было более выгодно купить маленький, быстрый диск для корня и подкачки и больший, более медленный диск для пользовательских данных (/usr
). До некоторой степени конвенция, просто застрявшая.
Однако существуют все еще некоторые причины того, чтобы сделать это. Несколько общих:
Помещение / загружается на отдельный, небольшой раздел близко к началу диска. Более старый ПК встроенное микропрограммное обеспечение BIOS только загрузился бы от первых 1 024 дорожек диска. Это, менее вероятно, будет проблемой с современными аппаратными средствами.
Помещение занятых разделов такой как /var
или /tmp
на отдельные диски для удаления узких мест на доступе к пользовательским данным.
Различные файловые системы на различных разделах. Например, можно хотеть использовать файловую систему журналирования для /usr
но не для разделов, которые размещают файлы для DBMS, такие как Oracle - DBMS делает свое собственное журналирование, и файловая система журналирования может наложить значительные издержки.
Наличие пользовательских данных по отдельному диску или разделу помогает переместить его на больший диск без обширного оперативного вмешательства на машине.
Можно хотеть смонтировать совместно используемые данные, такие как корневые каталоги или двоичные файлы приложения по NFS.
fsck
занимает много времени на больших объемах для определенных типов файловой системы. Можно хотеть иметь различные графики обслуживания файловой системы для системных (частых) областей и пользовательских (менее частых) областей.
Форматирование файловой системы может также быть быстрее, чем комната-rf'ing это. Особенно, если у Вас есть тысячи маленьких файлов для стирания. Кэш сквида Вы хотите полностью воссоздать... тонны файлов изображений, что Ваша потребность в обработке, но может быть выброшена после того, как конечный результат создается. файлы .obj от огромных компиляций... и т.д.
Папка я иногда ставил отдельный раздел, /usr/local/
так, чтобы любое программное обеспечение я создал и установил отдельно от диспетчера пакетов моего дистрибутива, мог возможно быть снова использован, если я изменяюсь/обновляю свой дистрибутив или другим дистрибутивом, установленным вдоль стороны это. Это, как очевидно, гарантируют, не будет работать через все возможные комбинации, но это не причиняет вреда.
Я поместил /tmp
на tmpfs, таким образом, содержание хранится в RAM вместо на диске. Это не было бы полезно для /etc
или /usr
как бы то ни было.
Но способность поместить различные каталоги на различные файловые системы могла быть выгодной; т.е. /home
в быстрой/экспериментальной файловой системе как ext4 по сравнению со стабильной/надежной файловой системой как ext2 для /etc
.
В некоторых ответах говорится о том, что /tmp
и /var
находятся на отдельных разделах, чтобы не заполнять /
, что может привести к поломке системы.
Но если у вас возникают проблемы с полным /
, обычно это происходит потому, что система не может создавать или записывать ни в /tmp
, ни в /var
, поэтому их размещение на отдельных разделах не поможет.
То есть, если /var
или /tmp
переполнятся, весьма вероятно, что ваша система будет вести себя неправильно.