ZIP-файл в формате FAT (для Linux)

lvdisplay --maps сообщит вам, где расположены физические экстенты, соответствующие конкретному LV или его определенному диапазону. pvdisplay --mapsпредставляет ту же информацию с точки зрения, ориентированной на PV -.

Например, если pvdisplay --mapsуказывает, что сбойный PV покрывает, скажем, логические экстенты 1000...4000 конкретного LV, а размер экстента этой VG составляет 4 МБ, то вы будете знать, что если PV полностью выйдет из строя, в вашем LV будет большая недоступная «дыра», начинающаяся с точки 4000 МБ от начала LV и продолжающаяся до точки 16000 МБ от начала этого LV.

Обычно в подобных ситуациях проще всего восстановить весь LV :, чтобы быть уверенным, что все файлы находятся в согласованном состоянии. Например, если файл A содержит ссылки на вещи из файла B, вы можете восстановить оба из резервных копий, даже если только один из них был в поврежденной области.

Но если вам необходимо (, т.е. вы обнаружили, что у вас нет пригодных для использования резервных копий и теперь у вас большие проблемы ), вы можете использовать lvchangeили vgchangeс --activationmode partial, чтобы активировать LV даже если в нем отсутствуют детали, чтобы вы могли установить его, чтобы восстановить то, что осталось. Это следует делать только в целях восстановления данных.

Поскольку в вашем случае /dev/sdbбудет первым PV в группе томов, он также будет содержать первую часть LV -, где, вероятно, окажется много критических метаданных файловой системы этого LV, поэтому fsckвыдал бы вам много ошибок. Как сказал frostschutz, photorecвполне может найти любые нефрагментированные файлы из оставшихся частей LV. Но полагаться на это — плохая стратегия.

Вам нужно будет подумать о резервных копиях и времени, которое займет полное восстановление. Если восстановление всего LV после сбоя диска займет слишком много времени, вам потребуется добавить в систему избыточность, чтобы избежать этого. Обычно это означает приобретение большего количества дисков и размещение данных на каком-либо массиве RAID.

Но даже если вы настроили RAID-массив, не забывайте о резервных копиях. RAID может упростить устранение сбоев диска, но он совершенно бесполезен в случае «упс» пользователя/сисадмина. RAID не является резервным.

1
06.04.2020, 16:05
4 ответа

Вам нужно разархивировать папку. Затем повторно заархивируйте его с опцией -k. Это даст вам 2.0 жир. Я не знаю, сработает ли это, но попробовать стоит. Вам нужно будет сделать это с помощью командной строки.

0
28.04.2021, 23:18

Вы можете сделать это с помощью Go:

package main
import (
   "archive/zip"
   "io"
   "os"
)
const creatorFAT = 0
func main() {
   // in
   file, _ := os.Open("in.txt")
   info, _ := file.Stat()
   head, _ := zip.FileInfoHeader(info)
   // default is Unix
   head.CreatorVersion = creatorFAT
   // out
   zipfile, _ := os.Create("out.zip")
   archive := zip.NewWriter(zipfile)
   // write
   writer, _ := archive.CreateHeader(head)
   io.Copy(writer, file)
   archive.Close()
}

Результат:

$ zipinfo out.zip
Archive:  out.zip
Zip file size: 151 bytes, number of entries: 1
-rw-rw-rw-  2.0 fat        7 bX stor 20-Apr-02 19:54 in.txt
1 file, 7 bytes uncompressed, 7 bytes compressed:  0.0%
0
28.04.2021, 23:18

Я думаю, что проблема связана с файлом _пользователя settings.wbxml Некоторые вещи там должны быть обновлены, вероятно, в зависимости от размера файла или количества контактов

0
28.04.2021, 23:18

Позвольте мне представить мой мощный инструмент, который делает это автоматическиhttps://github.com/pas-calc/nokia-contacts

Вы можете настроить этот скрипт под свои нужды. Что касается Python, вы должны придерживаться from zipfile import ZipFile.

0
28.04.2021, 23:18

Теги

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