Удалить empty & ldquo; lost + found & rdquo; папка автоматически, если она пуста

Question 1

Похоже, вам нужен учет процессов.

http://www.faqs.org/docs/Linux-mini/Process-Accounting.html

В Ubuntu процесс инструменты учета находятся в http://www.faqs.org/docs/Linux-mini/Process-Accounting.html

Чтобы получить отчет для каждого пользователя, запустите [ ! d7]

sa -m

Question 2

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

Question 3

Question 4

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

Question 5

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

Question 6

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

Question 7

Question 8

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

Question 9

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

Question 10

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, он поместит их в папку lost + found. Я предполагаю, что это в основном проблема с fsck , создающим эту папку, даже если ей нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку lost + found parent.

Например. для папки lost / found в '/':

echo "lost + found" | sudo tee /.hidden

Для одного в вашем домашнем каталоге (если есть):

echo "lost + found" & gt; ~ / .hidden

Предположим, что вы можете удалить их после каждой загрузки, добавив следующее в файл '/etc/rc.local':

 , если [-d / lost + found];  затем rmdir / lost + found 2 & gt; / dev / null fi, если [-d / home / USER / lost + found];  затем rmdir / home / USER / lost + found 2 & gt; / dev / null fi

Это приведет к запуску rmdir в папках, если они существуют, что только удаляет их если они пусты ( 2 & gt; / dev / null будет отбрасывать сообщение «не пусто» из rmdir ). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «exit 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы можете поставить выше в периодически выполняемое задание cron .

Question 11

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, он поместит их в папку lost + found. Я предполагаю, что это в основном проблема с fsck , создающим эту папку, даже если ей нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку lost + found parent.

Например. для папки lost / found в '/':

echo "lost + found" | sudo tee /.hidden

Для одного в вашем домашнем каталоге (если есть):

echo "lost + found" & gt; ~ / .hidden

Предположим, что вы можете удалить их после каждой загрузки, добавив следующее в файл '/etc/rc.local':

 , если [-d / lost + found];  затем rmdir / lost + found 2 & gt; / dev / null fi, если [-d / home / USER / lost + found];  затем rmdir / home / USER / lost + found 2 & gt; / dev / null fi

Это приведет к запуску rmdir в папках, если они существуют, что только удаляет их если они пусты ( 2 & gt; / dev / null будет отбрасывать сообщение «не пусто» из rmdir ). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «exit 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы можете поставить выше в периодически выполняемое задание cron .

Question 12

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, он поместит их в папку lost + found. Я предполагаю, что это в основном проблема с fsck , создающим эту папку, даже если ей нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку lost + found parent.

Например. для папки lost / found в '/':

echo "lost + found" | sudo tee /.hidden

Для одного в вашем домашнем каталоге (если есть):

echo "lost + found" & gt; ~ / .hidden

Предположим, что вы можете удалить их после каждой загрузки, добавив следующее в файл '/etc/rc.local':

 , если [-d / lost + found];  затем rmdir / lost + found 2 & gt; / dev / null fi, если [-d / home / USER / lost + found];  затем rmdir / home / USER / lost + found 2 & gt; / dev / null fi

Это приведет к запуску rmdir в папках, если они существуют, что только удаляет их если они пусты ( 2 & gt; / dev / null будет отбрасывать сообщение «не пусто» из rmdir ). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «exit 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы можете поставить выше в периодически выполняемое задание cron .

Question 13

Question 14

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, он поместит их в папку lost + found. Я предполагаю, что это в основном проблема с fsck , создающим эту папку, даже если ей нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку lost + found parent.

Например. для папки lost / found в '/':

echo "lost + found" | sudo tee /.hidden

Для одного в вашем домашнем каталоге (если есть):

echo "lost + found" & gt; ~ / .hidden

Предположим, что вы можете удалить их после каждой загрузки, добавив следующее в файл '/etc/rc.local':

 , если [-d / lost + found];  затем rmdir / lost + found 2 & gt; / dev / null fi, если [-d / home / USER / lost + found];  затем rmdir / home / USER / lost + found 2 & gt; / dev / null fi

Это приведет к запуску rmdir в папках, если они существуют, что только удаляет их если они пусты ( 2 & gt; / dev / null будет отбрасывать сообщение «не пусто» из rmdir ). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «exit 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы можете поставить выше в периодически выполняемое задание cron .

Question 15

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Question 16

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

Question 17

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

Question 18

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

Question 19

Question 20

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Question 21

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

Question 22

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

Question 23

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Question 24

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

Question 25

Question 26

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

Question 27

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Question 28

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

Question 29

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

Question 30

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Question 31

Question 32

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

Question 33

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

Question 34

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Question 35

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

Question 36

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

Question 37

Question 38

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до соответствующего размера.

[fsck попытается создать lost + found, если он не существует], , но перед лицом поврежденной файловой системы это может быть более рискованным.

Very старые fsck для других файловых систем на других платформах не смогли создать / потеряли + найденные и не смогли их вырастить. Это история для обоснования /lost+found...

Это требуется гораздо реже, чем ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

htorque · Accepted Answer · 26 May 2018 в 00:31

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

Спасибо, я знал это, но это решение работает только для nautilus. — Juan Simón, 10 November 2010 в 17:11
И как я могу скрыть эту папку на NFS? — Juan Simón, 10 November 2010 в 17:35
См. Обновление. К сожалению, у меня нет опыта работы с NFS. — htorque, 10 November 2010 в 17:43

htorque · Accepted Answer · 25 July 2018 в 22:55

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

htorque · Accepted Answer · 27 July 2018 в 01:24

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

htorque · Accepted Answer · 31 July 2018 в 11:00

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

htorque · Accepted Answer · 31 July 2018 в 11:59

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

htorque · Accepted Answer · 2 August 2018 в 04:18

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, она помещает их в папку lost + found. Я предполагаю, что это проблема с fsck созданием этой папки, даже если в нее нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление этого файла не будет работать. [ ! d0]

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку потерянного + найденного родителя.

Например. для папки lost / found в '/':

echo "lost+found" | sudo tee /.hidden

Для того, что находится в вашем домашнем каталоге (если есть):

echo "lost+found" > ~/.hidden

Я предполагаю, что в качестве альтернативы вы можете удалить их после каждой загрузки, добавив в файл '/etc/rc.local':

следующее:

if [ -d /lost+found ]; then
    rmdir /lost+found 2>/dev/null
fi

if [ -d /home/USER/lost+found ]; then
    rmdir /home/USER/lost+found 2>/dev/null
fi

Это запустит rmdir в папках, если они существуют, и только удаляет их, если они пусты (2>/dev/null отбрасывает сообщение «не пусто» из rmdir). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «выход 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы могли бы поставить выше в периодически выполняемое задание cron.

htorque · Accepted Answer · 6 August 2018 в 04:22

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, он поместит их в папку lost + found. Я предполагаю, что это в основном проблема с fsck , создающим эту папку, даже если ей нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку lost + found parent.

Например. для папки lost / found в '/':

echo "lost + found" | sudo tee /.hidden

Для одного в вашем домашнем каталоге (если есть):

echo "lost + found" & gt; ~ / .hidden

Предположим, что вы можете удалить их после каждой загрузки, добавив следующее в файл '/etc/rc.local':

 , если [-d / lost + found];  затем rmdir / lost + found 2 & gt; / dev / null fi, если [-d / home / USER / lost + found];  затем rmdir / home / USER / lost + found 2 & gt; / dev / null fi

Это приведет к запуску rmdir в папках, если они существуют, что только удаляет их если они пусты ( 2 & gt; / dev / null будет отбрасывать сообщение «не пусто» из rmdir ). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «exit 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы можете поставить выше в периодически выполняемое задание cron .

htorque · Accepted Answer · 7 August 2018 в 22:29

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, он поместит их в папку lost + found. Я предполагаю, что это в основном проблема с fsck , создающим эту папку, даже если ей нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку lost + found parent.

Например. для папки lost / found в '/':

echo "lost + found" | sudo tee /.hidden

Для одного в вашем домашнем каталоге (если есть):

echo "lost + found" & gt; ~ / .hidden

Предположим, что вы можете удалить их после каждой загрузки, добавив следующее в файл '/etc/rc.local':

 , если [-d / lost + found];  затем rmdir / lost + found 2 & gt; / dev / null fi, если [-d / home / USER / lost + found];  затем rmdir / home / USER / lost + found 2 & gt; / dev / null fi

Это приведет к запуску rmdir в папках, если они существуют, что только удаляет их если они пусты ( 2 & gt; / dev / null будет отбрасывать сообщение «не пусто» из rmdir ). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «exit 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы можете поставить выше в периодически выполняемое задание cron .

htorque · Accepted Answer · 10 August 2018 в 10:37

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, он поместит их в папку lost + found. Я предполагаю, что это в основном проблема с fsck , создающим эту папку, даже если ей нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку lost + found parent.

Например. для папки lost / found в '/':

echo "lost + found" | sudo tee /.hidden

Для одного в вашем домашнем каталоге (если есть):

echo "lost + found" & gt; ~ / .hidden

Предположим, что вы можете удалить их после каждой загрузки, добавив следующее в файл '/etc/rc.local':

 , если [-d / lost + found];  затем rmdir / lost + found 2 & gt; / dev / null fi, если [-d / home / USER / lost + found];  затем rmdir / home / USER / lost + found 2 & gt; / dev / null fi

Это приведет к запуску rmdir в папках, если они существуют, что только удаляет их если они пусты ( 2 & gt; / dev / null будет отбрасывать сообщение «не пусто» из rmdir ). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «exit 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы можете поставить выше в периодически выполняемое задание cron .

htorque · Accepted Answer · 13 August 2018 в 17:09

Всякий раз, когда fsck проходит через систему и пытается восстановить поврежденные файлы, он поместит их в папку lost + found. Я предполагаю, что это в основном проблема с fsck , создающим эту папку, даже если ей нечего вставлять. Поскольку Ubuntu периодически запускает эти проверки на ваших разделах, эти папки всегда будут воссозданы, поэтому удаление

Если вы просто хотите скрыть папку от Nautilus, вы можете создать файл «.hidden», содержащий «lost + found», и поместить его в папку lost + found parent.

Например. для папки lost / found в '/':

echo "lost + found" | sudo tee /.hidden

Для одного в вашем домашнем каталоге (если есть):

echo "lost + found" & gt; ~ / .hidden

Предположим, что вы можете удалить их после каждой загрузки, добавив следующее в файл '/etc/rc.local':

 , если [-d / lost + found];  затем rmdir / lost + found 2 & gt; / dev / null fi, если [-d / home / USER / lost + found];  затем rmdir / home / USER / lost + found 2 & gt; / dev / null fi

Это приведет к запуску rmdir в папках, если они существуют, что только удаляет их если они пусты ( 2 & gt; / dev / null будет отбрасывать сообщение «не пусто» из rmdir ). Там, вероятно, не так много каталогов, поэтому я сохранил это просто. Просто убедитесь, что «exit 0» остается в нижней строке.

Даунсайд: это только отслеживает каталоги, созданные fsck во время загрузки. Если он будет запущен позднее, вы снова увидите этот каталог. Затем вы можете поставить выше в периодически выполняемое задание cron .

Спасибо, я знал это, но это решение работает только для nautilus. — Juan Simón, 10 November 2010 в 17:11
И как я могу скрыть эту папку на NFS? — Juan Simón, 10 November 2010 в 17:35
См. Обновление. К сожалению, у меня нет опыта работы с NFS. — htorque, 10 November 2010 в 17:43

Community · Answer 11 · 26 May 2018 в 00:31

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Спасибо, но это не отвечает на мой вопрос. — Juan Simón, 10 November 2010 в 17:10

aneeshep · Answer 12 · 26 May 2018 в 00:31

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

0

ответ дан aneeshep 26 May 2018 в 00:31

1

Спасибо, я знал это, но это не отвечает на мой вопрос. – Juan Simón 10 November 2010 в 17:11
2

Хотя это теоретически может ответить на вопрос , было бы предпочтительно включить здесь основные части ответа и предоставить ссылку для справки. – Eliah Kagan 15 August 2012 в 10:28

Eliah Kagan · Answer 13 · 26 May 2018 в 00:31

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

-1

ответ дан Eliah Kagan 26 May 2018 в 00:31

aneeshep · Answer 14 · 25 July 2018 в 22:55

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

0

ответ дан aneeshep 25 July 2018 в 22:55

1

Спасибо, я знал это, но это не отвечает на мой вопрос. – Juan Simón 10 November 2010 в 17:11
2

Хотя это теоретически может ответить на вопрос , было бы предпочтительно включить здесь основные части ответа и предоставить ссылку для справки. – Eliah Kagan 15 August 2012 в 10:28

Community · Answer 15 · 25 July 2018 в 22:55

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Спасибо, но это не отвечает на мой вопрос. — Juan Simón, 10 November 2010 в 17:10

Eliah Kagan · Answer 16 · 25 July 2018 в 22:55

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

-1

ответ дан Eliah Kagan 25 July 2018 в 22:55

aneeshep · Answer 17 · 27 July 2018 в 01:24

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

0

ответ дан aneeshep 27 July 2018 в 01:24

1

Спасибо, я знал это, но это не отвечает на мой вопрос. – Juan Simón 10 November 2010 в 17:11
2

Хотя это теоретически может ответить на вопрос , было бы предпочтительно включить здесь основные части ответа и предоставить ссылку для справки. – Eliah Kagan 15 August 2012 в 10:28

Community · Answer 18 · 27 July 2018 в 01:24

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Спасибо, но это не отвечает на мой вопрос. — Juan Simón, 10 November 2010 в 17:10

Eliah Kagan · Answer 19 · 27 July 2018 в 01:24

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

-1

ответ дан Eliah Kagan 27 July 2018 в 01:24

aneeshep · Answer 20 · 31 July 2018 в 11:00

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

0

ответ дан aneeshep 31 July 2018 в 11:00

1

Спасибо, я знал это, но это не отвечает на мой вопрос. – Juan Simón 10 November 2010 в 17:11
2

Хотя это теоретически может ответить на вопрос , было бы предпочтительно включить здесь основные части ответа и предоставить ссылку для справки. – Eliah Kagan 15 August 2012 в 10:28

Community · Answer 21 · 31 July 2018 в 11:00

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Спасибо, но это не отвечает на мой вопрос. — Juan Simón, 10 November 2010 в 17:10

Eliah Kagan · Answer 22 · 31 July 2018 в 11:00

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

-1

ответ дан Eliah Kagan 31 July 2018 в 11:00

aneeshep · Answer 23 · 31 July 2018 в 11:59

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

0

ответ дан aneeshep 31 July 2018 в 11:59

1

Спасибо, я знал это, но это не отвечает на мой вопрос. – Juan Simón 10 November 2010 в 17:11
2

Хотя это теоретически может ответить на вопрос , было бы предпочтительно включить здесь основные части ответа и предоставить ссылку для справки. – Eliah Kagan 15 August 2012 в 10:28

Community · Answer 24 · 31 July 2018 в 11:59

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Спасибо, но это не отвечает на мой вопрос. — Juan Simón, 10 November 2010 в 17:10

Eliah Kagan · Answer 25 · 31 July 2018 в 11:59

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

-1

ответ дан Eliah Kagan 31 July 2018 в 11:59

aneeshep · Answer 26 · 2 August 2018 в 04:18

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

0

ответ дан aneeshep 2 August 2018 в 04:18

1

Спасибо, я знал это, но это не отвечает на мой вопрос. – Juan Simón 10 November 2010 в 17:11
2

Хотя это теоретически может ответить на вопрос , было бы предпочтительно включить здесь основные части ответа и предоставить ссылку для справки. – Eliah Kagan 15 August 2012 в 10:28

Community · Answer 27 · 2 August 2018 в 04:18

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до нужного размера. [fsck попытается создать lost + found, если он не существует], но перед лицом поврежденной файловой системы это может быть более рискованным. Очень старые fsck для других файловых систем на других платформах не смогли создать / потерять + найденные, и они не смогли его вырастить. Это история для обоснования / потерянного + найденного ...

Это нужно гораздо реже, так как ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Спасибо, но это не отвечает на мой вопрос. — Juan Simón, 10 November 2010 в 17:10

Eliah Kagan · Answer 28 · 2 August 2018 в 04:18

cd where the lost+found folder is located sudo touch .hidden sudo mcedit .hidden (Напишите lost+found и сохраните с помощью F2.)

-1

ответ дан Eliah Kagan 2 August 2018 в 04:18

aneeshep · Answer 29 · 6 August 2018 в 04:22

В этой статье вы найдете правильное объяснение о каталоге lost + found: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html

Community · Answer 30 · 6 August 2018 в 04:22

[Имея] потерянный + найденный каталог с достаточно большим размером, чтобы содержать большое количество несвязанных файлов, ставит меньше нагрузки на e2fsck, чтобы создать каталог и увеличить его до соответствующего размера.

[fsck попытается создать lost + found, если он не существует], , но перед лицом поврежденной файловой системы это может быть более рискованным.

Very старые fsck для других файловых систем на других платформах не смогли создать / потеряли + найденные и не смогли их вырастить. Это история для обоснования /lost+found...

Это требуется гораздо реже, чем ext3. С файловой системой журналов файлы не должны «потеряться» при сбое при сбое / сбое. Вы можете утверждать, что это нужно избегать фатальных сюрпризов для старожилов (и странных людей, которые отключили журнал). Если вы не знаете, что вам не хватает, возможно, это не проблема.

Тем не менее, удаление происходит как исправление e2fsck. Вы «можете» это сделать, но не должны.

Удалить empty & ldquo; lost + found & rdquo; папка автоматически, если она пуста

40 ответов

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

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