Hard-link / home / myuser в новом месте?

Я полагаю, что Apple в конечном итоге придется рассматривать такую ​​же вещь, когда у них заканчиваются кошки. Возможно, у них будет «Кошка Шредингера», а затем перейдем к чему-то еще. (Подумайте об этом, я хочу, чтобы у нас мог быть «кот Шредингера!». Может быть, ему придется ждать «Ubuntu для квантовых вычислений».)

2
задан 19 May 2012 в 17:59

13 ответов

Жесткие ссылки вообще не особенно проблематичны. Но жесткие ссылки на каталоги - вот почему вы должны использовать флаг -d, чтобы попытаться сделать это, и почему вы, вероятно, не добьетесь успеха; ядро, вероятно, сконфигурировано (или жестко запрограммировано, я не уверен), чтобы запретить их.

Кроме того, поскольку вы подозреваете, что не можете сильно связать что-либо через тома, так что вы не сможете к жесткой ссылке /home/myuser в каталог на другом разделе.

Существует два типа ссылок, поддерживаемых командой ln - Жесткие ссылки и софт-ссылки ( также называемые каталогами или symlinks).

A ln в файл ничего файла. Когда вы делаете жесткую ссылку, вы делаете ее так, чтобы другое имя файла идентифицировало файл. Файлы в файловой системе в стиле Unix (например, ext4, которые Ubuntu использует по умолчанию) однозначно идентифицируются их софт-ссылками . Когда файл имеет несколько имен, то есть несколько жестких ссылок (или, можно сказать, просто несколько ссылок), он продолжает существовать, даже если один или несколько из них удалены, если останется хотя бы один. (Затем он продолжает существовать на диске, пока он больше не будет открыт каким-либо процессом.) По этой причине имя низкоуровневой системной функции, выполняющей работу rm, называется unlink.

Файловая система не является файлом. Вместо этого это особый вид записи файловой системы, указывающий на файл по месту и имени целевого файла. Если вы удалите файл, на который указывает мягкая ссылка, эта программа не приведет к продолжению существования файла. Если вы удаляете или перемещаете / переименовываете файл, на который указывает мягкая ссылка, мягкая ссылка перестает работать для доступа к файлу и считается сломанной.

Жесткие ссылки на файлы по томам не работают, потому что жесткая ссылка - это файл и должна находиться на том, где физически хранятся данные файла.

Жесткие каталоги ссылок (то есть имеющие более одного имени, соответствующего одному и тому же каталогу) обычно плохо идея, и обычно запрещается, поскольку она позволяет разорвать основные (и разумные) предположения о том, как ведут себя каталоги. Например, предположим, что я попал в каталог с именем foo и I cd в каталог с именем bar. Если жесткие ссылки каталога не разрешены, я знаю, что с cd .. я могу вернуться к foo. Но если разрешены жесткие ссылки каталога, тогда bar может быть жесткой ссылкой на каталог в другом месте. Кроме того, и, что более серьезно, является , а жесткая ссылка на каталог - это каталог, поэтому может возникнуть неоднозначность в отношении того, какой каталог действительно является родителем bar.

С другой стороны, мягкие ссылки на каталоги прекрасно разрешены. Каталог foo может содержать софт-ссылку под названием bar, которая ссылается на каталог где-то в другом месте, но это не вызывает проблем, потому что всегда ясно, что делать. Это всегда понятно, потому что есть ответ на вопрос, в какой директории я на самом деле? Поэтому, когда вы обрабатываете настоящий рабочий каталог как имя, которое вы использовали для его получения, это имя символической ссылки. И когда вам нужно знать, в какой директории вы находитесь (например, чтобы сравнить два разных пути, чтобы убедиться, что они одинаковые или один находится в другом), это тоже работает.

So , какой каталог я действительно на самом деле? . Чтобы сделать мягкую ссылку, используйте ln -s target source. Вам не нужно (и не следует) указывать флаг -d для создания мягкой ссылки каталога.

Это может помочь улучшить вашу проблему. Вы можете попробовать. Но было бы лучше решить проблему самостоятельно. Я рекомендую вам опубликовать новый вопрос о том, как решить проблему с некоторыми из ваших программ, которые не работают должным образом, поскольку вы перенесли домашний каталог на другой раздел (предполагая, что это то, что вы сделали). Обязательно укажите конкретную информацию обо всех программах, которые имеют проблемы, включая полный и точный текст любых сообщений об ошибках, а также описание того, какие изменения вы внесли в конфигурацию Ubuntu, вызвавшую эти проблемы, и полное содержимое cd и выход echo $USER $HOME. (Вы также должны ссылаться на этот вопрос, чтобы люди не отвечали, говоря, что вы просто работаете над проблемой, создавая символическую ссылку.)

5
ответ дан 25 May 2018 в 11:13
  • 1
    Это отвечает на мой вопрос, спасибо. Я кратко рассмотрел символические ссылки, но если я удалю файл, например. Dropbox Я хочу, чтобы он действительно был удален, и я не думаю, что получаю это с символической ссылкой. Я раньше не думал о различии между связыванием файлов и ссылками на каталоги, поэтому спасибо за это. – Ari B. Friedman 19 May 2012 в 19:01
  • 2
    @ gsk3 Почему символические ссылки будут проблемой для dropbox? (Я не говорю, что они не будут, я не использую dropbox. Но ...) Симлинк будет только из старого домашнего каталога в новый домашний каталог. Файлы внутри не все будут символическими ссылками. Если foo является символической ссылкой на каталог bar, который содержит файл (или подкаталог) baz, тогда foo/baz является baz, а не символической ссылкой на baz. – Eliah Kagan 19 May 2012 в 19:09
  • 3
    Хорошая точка зрения. Пробовал, и, похоже, работает. +3 для вас. – Ari B. Friedman 19 May 2012 в 19:54

Жесткие ссылки вообще не особенно проблематичны. Но жесткие ссылки на каталоги - вот почему вы должны использовать флаг -d, чтобы попытаться сделать это, и почему вы, вероятно, не добьетесь успеха; ядро, вероятно, настроено (или жестко запрограммировано, я не уверен), чтобы их запретить.

Кроме того, поскольку вы подозреваете, что не можете жестко связать все между томами, поэтому вы не сможете жестко связать /home/myuser с каталогом на другом разделе.

Существует два типа ссылок, поддерживаемых командой ln жесткие ссылки и софт-ссылки (также называемые символическими ссылками или символическими ссылками).

Жесткая ссылка в файл является файлом. Когда вы делаете жесткую ссылку, вы делаете ее так, чтобы другое имя файла идентифицировало файл. Файлы в файловой системе в стиле Unix (например, ext4 , которые по умолчанию использует Ubuntu) однозначно идентифицируются их номером inode . Когда файл имеет несколько имен, то есть несколько жестких ссылок (или, можно сказать, просто несколько ссылок), он продолжает существовать, даже если один или несколько из них удалены, если останется хотя бы один. (Затем он продолжает существовать на диске, пока он больше не будет открыт каким-либо процессом.) Имя низкоуровневой системной функции, выполняющей работу rm , называется unlink по этой причине.

Программная ссылка не является файлом. Вместо этого это особый вид записи файловой системы, указывающий на файл по месту и имени целевого файла. Если вы удалите файл, на который указывает мягкая ссылка, эта программа не приведет к продолжению существования файла. Если вы удаляете или перемещаете / переименовываете файл, на который указывает мягкая ссылка, мягкая ссылка перестает работать для доступа к файлу и, как говорят, сломана.

Жесткие ссылки на файлы по томам не работают, потому что жесткая ссылка является файлом и должна находиться на том, где физически хранятся данные файла.

Жесткие каталоги ссылок (то есть имеющие более одного имени, соответствующего одному и тому же directory inode), как правило, является плохой идеей и обычно запрещается, поскольку она позволяет разбить базовые (и разумные) предположения о том, как ведут себя каталоги. Например, предположим, что я попал в каталог с именем foo и I cd в каталог с именем bar. Если жесткие ссылки каталога не разрешены, я знаю, что с cd .. я могу вернуться к foo. Но если разрешены жесткие ссылки каталога, тогда bar может быть жесткой ссылкой на каталог в другом месте. Кроме того, и, что более серьезно, жесткая ссылка - это файл , а жесткая ссылка на каталог - это каталог, поэтому может возникнуть неоднозначность в отношении того, какая директория действительно является родительским элементом bar.

С другой стороны, мягкие ссылки на каталоги прекрасно разрешены. Каталог foo может содержать софт-ссылку под названием bar, которая ссылается на каталог где-то в другом месте, но это не вызывает проблем, потому что всегда ясно, что делать. Это всегда ясно, потому что есть ответ на вопрос , в каком каталоге я действительно нахожусь? Итак, когда вы рассматриваете текущий рабочий каталог как имя, которое вы использовали для его получения, это имя символического ссылка на сайт. И когда вам нужно знать, в какой директории вы находитесь (например, чтобы сравнить два разных пути, чтобы убедиться, что они одинаковые или один находится в другом), это тоже работает.

So , вы можете сделать мягкую ссылку или символическую ссылку с /home/myuser в новый домашний каталог. Чтобы сделать мягкую ссылку, используйте ln -s target source. Вам не нужно (и не должно) указывать флаг -d для создания мягкой ссылки каталога.

Это может помочь улучшить вашу проблему. Вы можете попробовать. Но было бы лучше решить проблему самостоятельно. Я рекомендую вам опубликовать новый вопрос о том, как решить проблему с некоторыми из ваших программ, которые не работают должным образом, поскольку вы перенесли домашний каталог на другой раздел (предполагая, что это то, что вы сделали). Обязательно укажите конкретную информацию обо всех программах, которые имеют проблемы, включая полный и точный текст любых сообщений об ошибках, а также описание того, какие изменения вы внесли в конфигурацию Ubuntu, вызвавшую эти проблемы, и полное содержимое /etc/fstab и выход echo $USER $HOME. (Вы также должны ссылаться на этот вопрос, чтобы люди не отвечали, говоря вам, что вы просто работаете над проблемой, создавая символическую ссылку.)

5
ответ дан 25 July 2018 в 18:50

Жесткие ссылки вообще не особенно проблематичны. Но жесткие ссылки на каталоги - вот почему вы должны использовать флаг -d, чтобы попытаться сделать это, и почему вы, вероятно, не добьетесь успеха; ядро, вероятно, настроено (или жестко запрограммировано, я не уверен), чтобы их запретить.

Кроме того, поскольку вы подозреваете, что не можете жестко связать все между томами, поэтому вы не сможете жестко связать /home/myuser с каталогом на другом разделе.

Существует два типа ссылок, поддерживаемых командой ln жесткие ссылки и софт-ссылки (также называемые символическими ссылками или символическими ссылками).

Жесткая ссылка в файл является файлом. Когда вы делаете жесткую ссылку, вы делаете ее так, чтобы другое имя файла идентифицировало файл. Файлы в файловой системе в стиле Unix (например, ext4 , которые по умолчанию использует Ubuntu) однозначно идентифицируются их номером inode . Когда файл имеет несколько имен, то есть несколько жестких ссылок (или, можно сказать, просто несколько ссылок), он продолжает существовать, даже если один или несколько из них удалены, если останется хотя бы один. (Затем он продолжает существовать на диске, пока он больше не будет открыт каким-либо процессом.) Имя низкоуровневой системной функции, выполняющей работу rm , называется unlink по этой причине.

Программная ссылка не является файлом. Вместо этого это особый вид записи файловой системы, указывающий на файл по месту и имени целевого файла. Если вы удалите файл, на который указывает мягкая ссылка, эта программа не приведет к продолжению существования файла. Если вы удаляете или перемещаете / переименовываете файл, на который указывает мягкая ссылка, мягкая ссылка перестает работать для доступа к файлу и, как говорят, сломана.

Жесткие ссылки на файлы по томам не работают, потому что жесткая ссылка является файлом и должна находиться на том, где физически хранятся данные файла.

Жесткие каталоги ссылок (то есть имеющие более одного имени, соответствующего одному и тому же directory inode), как правило, является плохой идеей и обычно запрещается, поскольку она позволяет разбить базовые (и разумные) предположения о том, как ведут себя каталоги. Например, предположим, что я попал в каталог с именем foo и I cd в каталог с именем bar. Если жесткие ссылки каталога не разрешены, я знаю, что с cd .. я могу вернуться к foo. Но если разрешены жесткие ссылки каталога, тогда bar может быть жесткой ссылкой на каталог в другом месте. Кроме того, и, что более серьезно, жесткая ссылка - это файл , а жесткая ссылка на каталог - это каталог, поэтому может возникнуть неоднозначность в отношении того, какая директория действительно является родительским элементом bar.

С другой стороны, мягкие ссылки на каталоги прекрасно разрешены. Каталог foo может содержать софт-ссылку под названием bar, которая ссылается на каталог где-то в другом месте, но это не вызывает проблем, потому что всегда ясно, что делать. Это всегда ясно, потому что есть ответ на вопрос , в каком каталоге я действительно нахожусь? Итак, когда вы рассматриваете текущий рабочий каталог как имя, которое вы использовали для его получения, это имя символического ссылка на сайт. И когда вам нужно знать, в какой директории вы находитесь (например, чтобы сравнить два разных пути, чтобы убедиться, что они одинаковые или один находится в другом), это тоже работает.

So , вы можете сделать мягкую ссылку или символическую ссылку с /home/myuser в новый домашний каталог. Чтобы сделать мягкую ссылку, используйте ln -s target source. Вам не нужно (и не должно) указывать флаг -d для создания мягкой ссылки каталога.

Это может помочь улучшить вашу проблему. Вы можете попробовать. Но было бы лучше решить проблему самостоятельно. Я рекомендую вам опубликовать новый вопрос о том, как решить проблему с некоторыми из ваших программ, которые не работают должным образом, поскольку вы перенесли домашний каталог на другой раздел (предполагая, что это то, что вы сделали). Обязательно укажите конкретную информацию обо всех программах, которые имеют проблемы, включая полный и точный текст любых сообщений об ошибках, а также описание того, какие изменения вы внесли в конфигурацию Ubuntu, вызвавшую эти проблемы, и полное содержимое /etc/fstab и выход echo $USER $HOME. (Вы также должны ссылаться на этот вопрос, чтобы люди не отвечали, говоря вам, что вы просто работаете над проблемой, создавая символическую ссылку.)

5
ответ дан 2 August 2018 в 00:59

Жесткие ссылки вообще не особенно проблематичны. Но жесткие ссылки на каталоги - вот почему вы должны использовать флаг -d, чтобы попытаться сделать это, и почему вы, вероятно, не добьетесь успеха; ядро, вероятно, настроено (или жестко запрограммировано, я не уверен), чтобы их запретить.

Кроме того, поскольку вы подозреваете, что не можете жестко связать все между томами, поэтому вы не сможете жестко связать /home/myuser с каталогом на другом разделе.

Существует два типа ссылок, поддерживаемых командой ln жесткие ссылки и софт-ссылки (также называемые символическими ссылками или символическими ссылками).

Жесткая ссылка в файл является файлом. Когда вы делаете жесткую ссылку, вы делаете ее так, чтобы другое имя файла идентифицировало файл. Файлы в файловой системе в стиле Unix (например, ext4 , которые по умолчанию использует Ubuntu) однозначно идентифицируются их номером inode . Когда файл имеет несколько имен, то есть несколько жестких ссылок (или, можно сказать, просто несколько ссылок), он продолжает существовать, даже если один или несколько из них удалены, если останется хотя бы один. (Затем он продолжает существовать на диске, пока он больше не будет открыт каким-либо процессом.) Имя низкоуровневой системной функции, выполняющей работу rm , называется unlink по этой причине.

Программная ссылка не является файлом. Вместо этого это особый вид записи файловой системы, указывающий на файл по месту и имени целевого файла. Если вы удалите файл, на который указывает мягкая ссылка, эта программа не приведет к продолжению существования файла. Если вы удаляете или перемещаете / переименовываете файл, на который указывает мягкая ссылка, мягкая ссылка перестает работать для доступа к файлу и, как говорят, сломана.

Жесткие ссылки на файлы по томам не работают, потому что жесткая ссылка является файлом и должна находиться на том, где физически хранятся данные файла.

Жесткие каталоги ссылок (то есть имеющие более одного имени, соответствующего одному и тому же directory inode), как правило, является плохой идеей и обычно запрещается, поскольку она позволяет разбить базовые (и разумные) предположения о том, как ведут себя каталоги. Например, предположим, что я попал в каталог с именем foo и I cd в каталог с именем bar. Если жесткие ссылки каталога не разрешены, я знаю, что с cd .. я могу вернуться к foo. Но если разрешены жесткие ссылки каталога, тогда bar может быть жесткой ссылкой на каталог в другом месте. Кроме того, и, что более серьезно, жесткая ссылка - это файл , а жесткая ссылка на каталог - это каталог, поэтому может возникнуть неоднозначность в отношении того, какая директория действительно является родительским элементом bar.

С другой стороны, мягкие ссылки на каталоги прекрасно разрешены. Каталог foo может содержать софт-ссылку под названием bar, которая ссылается на каталог где-то в другом месте, но это не вызывает проблем, потому что всегда ясно, что делать. Это всегда ясно, потому что есть ответ на вопрос , в каком каталоге я действительно нахожусь? Итак, когда вы рассматриваете текущий рабочий каталог как имя, которое вы использовали для его получения, это имя символического ссылка на сайт. И когда вам нужно знать, в какой директории вы находитесь (например, чтобы сравнить два разных пути, чтобы убедиться, что они одинаковые или один находится в другом), это тоже работает.

So , вы можете сделать мягкую ссылку или символическую ссылку с /home/myuser в новый домашний каталог. Чтобы сделать мягкую ссылку, используйте ln -s target source. Вам не нужно (и не должно) указывать флаг -d для создания мягкой ссылки каталога.

Это может помочь улучшить вашу проблему. Вы можете попробовать. Но было бы лучше решить проблему самостоятельно. Я рекомендую вам опубликовать новый вопрос о том, как решить проблему с некоторыми из ваших программ, которые не работают должным образом, поскольку вы перенесли домашний каталог на другой раздел (предполагая, что это то, что вы сделали). Обязательно укажите конкретную информацию обо всех программах, которые имеют проблемы, включая полный и точный текст любых сообщений об ошибках, а также описание того, какие изменения вы внесли в конфигурацию Ubuntu, вызвавшую эти проблемы, и полное содержимое /etc/fstab и выход echo $USER $HOME. (Вы также должны ссылаться на этот вопрос, чтобы люди не отвечали, говоря вам, что вы просто работаете над проблемой, создавая символическую ссылку.)

5
ответ дан 4 August 2018 в 16:30

Жесткие ссылки вообще не особенно проблематичны. Но жесткие ссылки на каталоги - вот почему вы должны использовать флаг -d, чтобы попытаться сделать это, и почему вы, вероятно, не добьетесь успеха; ядро, вероятно, настроено (или жестко запрограммировано, я не уверен), чтобы их запретить.

Кроме того, поскольку вы подозреваете, что не можете жестко связать все между томами, поэтому вы не сможете жестко связать /home/myuser с каталогом на другом разделе.

Существует два типа ссылок, поддерживаемых командой ln жесткие ссылки и софт-ссылки (также называемые символическими ссылками или символическими ссылками).

Жесткая ссылка в файл является файлом. Когда вы делаете жесткую ссылку, вы делаете ее так, чтобы другое имя файла идентифицировало файл. Файлы в файловой системе в стиле Unix (например, ext4 , которые по умолчанию использует Ubuntu) однозначно идентифицируются их номером inode . Когда файл имеет несколько имен, то есть несколько жестких ссылок (или, можно сказать, просто несколько ссылок), он продолжает существовать, даже если один или несколько из них удалены, если останется хотя бы один. (Затем он продолжает существовать на диске, пока он больше не будет открыт каким-либо процессом.) Имя низкоуровневой системной функции, выполняющей работу rm , называется unlink по этой причине.

Программная ссылка не является файлом. Вместо этого это особый вид записи файловой системы, указывающий на файл по месту и имени целевого файла. Если вы удалите файл, на который указывает мягкая ссылка, эта программа не приведет к продолжению существования файла. Если вы удаляете или перемещаете / переименовываете файл, на который указывает мягкая ссылка, мягкая ссылка перестает работать для доступа к файлу и, как говорят, сломана.

Жесткие ссылки на файлы по томам не работают, потому что жесткая ссылка является файлом и должна находиться на том, где физически хранятся данные файла.

Жесткие каталоги ссылок (то есть имеющие более одного имени, соответствующего одному и тому же directory inode), как правило, является плохой идеей и обычно запрещается, поскольку она позволяет разбить базовые (и разумные) предположения о том, как ведут себя каталоги. Например, предположим, что я попал в каталог с именем foo и I cd в каталог с именем bar. Если жесткие ссылки каталога не разрешены, я знаю, что с cd .. я могу вернуться к foo. Но если разрешены жесткие ссылки каталога, тогда bar может быть жесткой ссылкой на каталог в другом месте. Кроме того, и, что более серьезно, жесткая ссылка - это файл , а жесткая ссылка на каталог - это каталог, поэтому может возникнуть неоднозначность в отношении того, какая директория действительно является родительским элементом bar.

С другой стороны, мягкие ссылки на каталоги прекрасно разрешены. Каталог foo может содержать софт-ссылку под названием bar, которая ссылается на каталог где-то в другом месте, но это не вызывает проблем, потому что всегда ясно, что делать. Это всегда ясно, потому что есть ответ на вопрос , в каком каталоге я действительно нахожусь? Итак, когда вы рассматриваете текущий рабочий каталог как имя, которое вы использовали для его получения, это имя символического ссылка на сайт. И когда вам нужно знать, в какой директории вы находитесь (например, чтобы сравнить два разных пути, чтобы убедиться, что они одинаковые или один находится в другом), это тоже работает.

So , вы можете сделать мягкую ссылку или символическую ссылку с /home/myuser в новый домашний каталог. Чтобы сделать мягкую ссылку, используйте ln -s target source. Вам не нужно (и не должно) указывать флаг -d для создания мягкой ссылки каталога.

Это может помочь улучшить вашу проблему. Вы можете попробовать. Но было бы лучше решить проблему самостоятельно. Я рекомендую вам опубликовать новый вопрос о том, как решить проблему с некоторыми из ваших программ, которые не работают должным образом, поскольку вы перенесли домашний каталог на другой раздел (предполагая, что это то, что вы сделали). Обязательно укажите конкретную информацию обо всех программах, которые имеют проблемы, включая полный и точный текст любых сообщений об ошибках, а также описание того, какие изменения вы внесли в конфигурацию Ubuntu, вызвавшую эти проблемы, и полное содержимое /etc/fstab и выход echo $USER $HOME. (Вы также должны ссылаться на этот вопрос, чтобы люди не отвечали, говоря вам, что вы просто работаете над проблемой, создавая символическую ссылку.)

5
ответ дан 6 August 2018 в 01:10

Жесткие ссылки вообще не особенно проблематичны. Но жесткие ссылки на каталоги - вот почему вы должны использовать флаг -d, чтобы попытаться сделать это, и почему вы, вероятно, не добьетесь успеха; ядро, вероятно, настроено (или жестко запрограммировано, я не уверен), чтобы их запретить.

Кроме того, поскольку вы подозреваете, что не можете жестко связать все между томами, поэтому вы не сможете жестко связать /home/myuser с каталогом на другом разделе.

Существует два типа ссылок, поддерживаемых командой ln жесткие ссылки и софт-ссылки (также называемые символическими ссылками или символическими ссылками).

Жесткая ссылка в файл является файлом. Когда вы делаете жесткую ссылку, вы делаете ее так, чтобы другое имя файла идентифицировало файл. Файлы в файловой системе в стиле Unix (например, ext4 , которые по умолчанию использует Ubuntu) однозначно идентифицируются их номером inode . Когда файл имеет несколько имен, то есть несколько жестких ссылок (или, можно сказать, просто несколько ссылок), он продолжает существовать, даже если один или несколько из них удалены, если останется хотя бы один. (Затем он продолжает существовать на диске, пока он больше не будет открыт каким-либо процессом.) Имя низкоуровневой системной функции, выполняющей работу rm , называется unlink по этой причине.

Программная ссылка не является файлом. Вместо этого это особый вид записи файловой системы, указывающий на файл по месту и имени целевого файла. Если вы удалите файл, на который указывает мягкая ссылка, эта программа не приведет к продолжению существования файла. Если вы удаляете или перемещаете / переименовываете файл, на который указывает мягкая ссылка, мягкая ссылка перестает работать для доступа к файлу и, как говорят, сломана.

Жесткие ссылки на файлы по томам не работают, потому что жесткая ссылка является файлом и должна находиться на том, где физически хранятся данные файла.

Жесткие каталоги ссылок (то есть имеющие более одного имени, соответствующего одному и тому же directory inode), как правило, является плохой идеей и обычно запрещается, поскольку она позволяет разбить базовые (и разумные) предположения о том, как ведут себя каталоги. Например, предположим, что я попал в каталог с именем foo и I cd в каталог с именем bar. Если жесткие ссылки каталога не разрешены, я знаю, что с cd .. я могу вернуться к foo. Но если разрешены жесткие ссылки каталога, тогда bar может быть жесткой ссылкой на каталог в другом месте. Кроме того, и, что более серьезно, жесткая ссылка - это файл , а жесткая ссылка на каталог - это каталог, поэтому может возникнуть неоднозначность в отношении того, какая директория действительно является родительским элементом bar.

С другой стороны, мягкие ссылки на каталоги прекрасно разрешены. Каталог foo может содержать софт-ссылку под названием bar, которая ссылается на каталог где-то в другом месте, но это не вызывает проблем, потому что всегда ясно, что делать. Это всегда ясно, потому что есть ответ на вопрос , в каком каталоге я действительно нахожусь? Итак, когда вы рассматриваете текущий рабочий каталог как имя, которое вы использовали для его получения, это имя символического ссылка на сайт. И когда вам нужно знать, в какой директории вы находитесь (например, чтобы сравнить два разных пути, чтобы убедиться, что они одинаковые или один находится в другом), это тоже работает.

So , вы можете сделать мягкую ссылку или символическую ссылку с /home/myuser в новый домашний каталог. Чтобы сделать мягкую ссылку, используйте ln -s target source. Вам не нужно (и не должно) указывать флаг -d для создания мягкой ссылки каталога.

Это может помочь улучшить вашу проблему. Вы можете попробовать. Но было бы лучше решить проблему самостоятельно. Я рекомендую вам опубликовать новый вопрос о том, как решить проблему с некоторыми из ваших программ, которые не работают должным образом, поскольку вы перенесли домашний каталог на другой раздел (предполагая, что это то, что вы сделали). Обязательно укажите конкретную информацию обо всех программах, которые имеют проблемы, включая полный и точный текст любых сообщений об ошибках, а также описание того, какие изменения вы внесли в конфигурацию Ubuntu, вызвавшую эти проблемы, и полное содержимое /etc/fstab и выход echo $USER $HOME. (Вы также должны ссылаться на этот вопрос, чтобы люди не отвечали, говоря вам, что вы просто работаете над проблемой, создавая символическую ссылку.)

5
ответ дан 7 August 2018 в 18:36

Жесткие ссылки вообще не особенно проблематичны. Но жесткие ссылки на каталоги - вот почему вы должны использовать флаг -d, чтобы попытаться сделать это, и почему вы, вероятно, не добьетесь успеха; ядро, вероятно, настроено (или жестко запрограммировано, я не уверен), чтобы их запретить.

Кроме того, поскольку вы подозреваете, что не можете жестко связать все между томами, поэтому вы не сможете жестко связать /home/myuser с каталогом на другом разделе.

Существует два типа ссылок, поддерживаемых командой ln жесткие ссылки и софт-ссылки (также называемые символическими ссылками или символическими ссылками).

Жесткая ссылка в файл является файлом. Когда вы делаете жесткую ссылку, вы делаете ее так, чтобы другое имя файла идентифицировало файл. Файлы в файловой системе в стиле Unix (например, ext4 , которые по умолчанию использует Ubuntu) однозначно идентифицируются их номером inode . Когда файл имеет несколько имен, то есть несколько жестких ссылок (или, можно сказать, просто несколько ссылок), он продолжает существовать, даже если один или несколько из них удалены, если останется хотя бы один. (Затем он продолжает существовать на диске, пока он больше не будет открыт каким-либо процессом.) Имя низкоуровневой системной функции, выполняющей работу rm , называется unlink по этой причине.

Программная ссылка не является файлом. Вместо этого это особый вид записи файловой системы, указывающий на файл по месту и имени целевого файла. Если вы удалите файл, на который указывает мягкая ссылка, эта программа не приведет к продолжению существования файла. Если вы удаляете или перемещаете / переименовываете файл, на который указывает мягкая ссылка, мягкая ссылка перестает работать для доступа к файлу и, как говорят, сломана.

Жесткие ссылки на файлы по томам не работают, потому что жесткая ссылка является файлом и должна находиться на том, где физически хранятся данные файла.

Жесткие каталоги ссылок (то есть имеющие более одного имени, соответствующего одному и тому же directory inode), как правило, является плохой идеей и обычно запрещается, поскольку она позволяет разбить базовые (и разумные) предположения о том, как ведут себя каталоги. Например, предположим, что я попал в каталог с именем foo и I cd в каталог с именем bar. Если жесткие ссылки каталога не разрешены, я знаю, что с cd .. я могу вернуться к foo. Но если разрешены жесткие ссылки каталога, тогда bar может быть жесткой ссылкой на каталог в другом месте. Кроме того, и, что более серьезно, жесткая ссылка - это файл , а жесткая ссылка на каталог - это каталог, поэтому может возникнуть неоднозначность в отношении того, какая директория действительно является родительским элементом bar.

С другой стороны, мягкие ссылки на каталоги прекрасно разрешены. Каталог foo может содержать софт-ссылку под названием bar, которая ссылается на каталог где-то в другом месте, но это не вызывает проблем, потому что всегда ясно, что делать. Это всегда ясно, потому что есть ответ на вопрос , в каком каталоге я действительно нахожусь? Итак, когда вы рассматриваете текущий рабочий каталог как имя, которое вы использовали для его получения, это имя символического ссылка на сайт. И когда вам нужно знать, в какой директории вы находитесь (например, чтобы сравнить два разных пути, чтобы убедиться, что они одинаковые или один находится в другом), это тоже работает.

So , вы можете сделать мягкую ссылку или символическую ссылку с /home/myuser в новый домашний каталог. Чтобы сделать мягкую ссылку, используйте ln -s target source. Вам не нужно (и не должно) указывать флаг -d для создания мягкой ссылки каталога.

Это может помочь улучшить вашу проблему. Вы можете попробовать. Но было бы лучше решить проблему самостоятельно. Я рекомендую вам опубликовать новый вопрос о том, как решить проблему с некоторыми из ваших программ, которые не работают должным образом, поскольку вы перенесли домашний каталог на другой раздел (предполагая, что это то, что вы сделали). Обязательно укажите конкретную информацию обо всех программах, которые имеют проблемы, включая полный и точный текст любых сообщений об ошибках, а также описание того, какие изменения вы внесли в конфигурацию Ubuntu, вызвавшую эти проблемы, и полное содержимое /etc/fstab и выход echo $USER $HOME. (Вы также должны ссылаться на этот вопрос, чтобы люди не отвечали, говоря вам, что вы просто работаете над проблемой, создавая символическую ссылку.)

5
ответ дан 15 August 2018 в 19:17
  • 1
    Это отвечает на мой вопрос, спасибо. Я кратко рассмотрел символические ссылки, но если я удалю файл, например. Dropbox Я хочу, чтобы он действительно был удален, и я не думаю, что получаю это с символической ссылкой. Я раньше не думал о различии между связыванием файлов и ссылками на каталоги, поэтому спасибо за это. – Ari B. Friedman 19 May 2012 в 19:01
  • 2
    @ gsk3 Почему символические ссылки будут проблемой для dropbox? (Я не говорю, что они не будут, я не использую dropbox. Но ...) Симлинк будет только из старого домашнего каталога в новый домашний каталог. Файлы внутри не все будут символическими ссылками. Если foo является символической ссылкой на каталог bar, который содержит файл (или подкаталог) baz, тогда foo/baz является baz, а не символической ссылкой на baz. – Eliah Kagan 19 May 2012 в 19:09
  • 3
    Хорошая точка зрения. Пробовал, и, похоже, работает. +3 для вас. – Ari B. Friedman 19 May 2012 в 19:54

Не выполняйте жесткую ссылку. Сделайте символическую ссылку. [F1]. Жесткие ссылки могут вызвать проблемы, особенно когда они находятся в каталоге.

0
ответ дан 25 May 2018 в 11:13
  • 1
    Как упоминается в другом ответе, вы не можете создавать жесткие ссылки на каталоги в первую очередь. – Brian Z 10 June 2015 в 09:23

Не выполняйте жесткую ссылку. Сделайте символическую ссылку. ln -s /path/to/home /path/to/link. Жесткие ссылки могут вызывать проблемы, особенно если они относятся к каталогу.

0
ответ дан 25 July 2018 в 18:50

Не выполняйте жесткую ссылку. Сделайте символическую ссылку. ln -s /path/to/home /path/to/link. Жесткие ссылки могут вызывать проблемы, особенно когда они находятся в каталоге.

0
ответ дан 4 August 2018 в 16:30

Не выполняйте жесткую ссылку. Сделайте символическую ссылку. ln -s /path/to/home /path/to/link. Жесткие ссылки могут вызывать проблемы, особенно если они относятся к каталогу.

0
ответ дан 6 August 2018 в 01:10

Не выполняйте жесткую ссылку. Сделайте символическую ссылку. ln -s /path/to/home /path/to/link. Жесткие ссылки могут вызывать проблемы, особенно если они относятся к каталогу.

0
ответ дан 7 August 2018 в 18:36

Не выполняйте жесткую ссылку. Сделайте символическую ссылку. ln -s /path/to/home /path/to/link. Жесткие ссылки могут вызывать проблемы, особенно если они относятся к каталогу.

0
ответ дан 15 August 2018 в 19:17
  • 1
    Как упоминается в другом ответе, вы не можете создавать жесткие ссылки на каталоги в первую очередь. – Brian Z 10 June 2015 в 09:23

Другие вопросы по тегам:

Похожие вопросы: