>>180560168 (OP)
В архиваторе WinRAR по умолчанию каждый файл сжимается сам по себе. Поэтому все непроврежденные есть шанс восстановать.
В 7z в ультра сжатии используется так называемое "непрерывное" сжатие, где все файлы "объединяются" и затем сжимаются "как один". При повреждении вряд ли хоть что-то можно восстановить.

Из какого аниме оп пик ?

>>180560530
Darker than black

>>180560512
Да, читал про это, но надежда умирает последней.

>>180560596
А какую ошибку он выдает при попытке распаковать? Дай скрин.

>>180560559
Спасибо, няш.:3
Бамп за это тред тебе

Бумп, чёт тоже интересно стало.

Бумп.

Бамп ещё раз в поддержку опа

>>180560942
Вряд ли это поможет, но я бы попробывал такие варианты:
1.Изменить расширение архива с 7z на zip и всё-таки попытаться восстановить его через WinRar.
2.Подключить теплофон к компу и восстановить файлы непостредственно с теплофона.

Бамп такому хорошему ОПчику.

>>180561531
Когда меняешь расширение, winrar его все равно как 7z детектит и посылает ;(

С телефона это было перенесено на комп перед хард ресетом, так что единственный экземпляр (и его копия) сейчас лежат на пк.

>>180560168 (OP)
Ну, я знаю, что архивация это чё-то, связанное с криптографией, поэтому тебе нужен шарящий криптограф. Чем смог, тем помог.

>>180561658
При выполнении hard reset содержимое памяти при не меняется. Проще говоря, если ты просто сделал сброс настроек до заводских, то байты, по-идее, не должны измениться (если ты конечно не забил весь раздел нулями). Следовательно, может быть восстановление ещё возможно.

>>180561658
Всегда противно и неприятно, когда подобное происходит.

Анон, накидай плз побольше подобных пик 2д богинь а лучше ссылку на пак

>>180561876
К сожалению, там все файлы сносились, причем делалось это уже несколько раз, т.е. шансов тут никаких, полагаю ;(

Хотя пока я доработаю 3 часа тред умрет и я не увижу ни пикч ни пака.. тлен

>>180562000
Хотя бы попытайся. Сам же сказал, что надежда умирает последней >_>

бамп

>>180562051
Какой ты милый, сейчас погуглю, попытаюсь что-нибудь узнать по этой теме.

>>180560168 (OP)
сочувствую /б/рат, я понимаю какая это боль, ты там держись

>>180562051
Так. поискал, вот что нашёл.


If you try to open or extract archive and you see the message "Can not open file 'a.7z' as archive", it means that 7-Zip can't open some header from the start or from the end of archive.

In that case you must open archive in hex editor and look to Start Header and End Header.

Possible cases:

Case: If start of archive is corrupted, then there is no link to End Header. But if the End Header is OK, and the size of archive is also correct, you can replace data in Start Header in hex editor to the following values:
0000000000: 37 7A BC AF 27 1C 00 04 00 00 00 00 00 00 00 00
0000000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Then try to open archive, if you can open and you see the list of files, try Test or Extract command. Look also "Data errors or CRC errors" section in this page.

Case: Start Header and End Header are OK, but total size of archive is not OK. You can calculate correct size of archive from values in Start Header. Then you must recover correct size. You can insert some data or remove some data somewhere in archive (for example, at offset of several MBs before the end of archive).
For example, if you have multi-volume archive: a.7z.001, ... , a.7z.009, but one part a.7z.008 is missing, just copy a.7z.007 to file a.7z.008, and 7-Zip will see correct size of archive. Or if some part was reduced, look the size of another parts and restore original (correct) size of "bad" part, so total size will be correct again, and 7-zip will be able to open headers.

Case: The end of archive is corrupted or missing. The following text describes that case.

https://www.7-zip.org/recover.html

Сможешь сам сделать? Хекс едитор знаёшь че такое? С инглишом норм?

В винраре есть функция восстановления битого арихва, что-то да восстановится

>>180562222
Стараюсь довольствоваться тем немногим, что нашел по памяти, и жалею что не юзал облака для хранения файлов

>>180562051
В общем, если сжато(лол, каламбур), то с файлами всё ок, проблема с хидерами, их нужно поправить и всё будет ок, это в теории.

>>180562345
работает только для zip и rar, у меня же 7z формат ;(

>>180562316
сейчас посмотрим что там

>>180562430
гугли про восстановление этого формата, что-нибудь должно быть

>>180562481
в этом то и проблема, что гугл мне не помог (ну или я просто недалекий)

>>180562516
Ну а что там с заголовками?

>>180562464
Давай, а то так нужно будет архив скидывать.

бамп.

>>180562583
Судя по всему с началом что-то не ок. Во всяком случае, первые 2 строки не такие, как в примере.
Сейчас попробую их поменять - отпишусь что как.

>>180562988
Вроде всё ок.

Попробуй скачать Universal Extractor и им распаковать.

>>180562988
Relative offset of End Header is relative from the end of Start Header,
that is at offset 0x20 (32 in decimal).
Real offset of End Header in example archive = 0x20 + 0x0E59 = 0x0E79

Посчитай какое число получается.

>>180562988
Типа 0х27+0х5f59ceb7

>>180562988
0x5F59CEDE
По этому адресу должен лежать енд хидер.

>>180563490
>>180563597

0000000E70: 17 06 8D AD 01 09 80
0000000E80: AC 00 07 0B 01 00 01 23 03 01 01 05 5D 00 10 00
0000000E90: 00 0C 81 1A 0A 01 3C 70 52 F7 00 00

Possible values for first byte in End Header:
17 - End Header contains the link to Metadata Block.
01 - Metadata block is stored in End Header.

Ну я не вижу тут ни 17, ни 01 да и число байт не совпадает нихуя, должно быть 27, а тут 32.

>>180563671
Ща, давай ещё раз число перепроверю, а то я тут шавуху хаваю, может невнимательно. Если всё так, то повреждён конец. Дальше будем делать.

>>180563717
ок

бамп.

>>180563760
Короче всё правильно.


Case: The end of archive is corrupted or missing. The following text describes that case.
There is no correct End Header at the end of archive

>>180563760


Note: If archive is multi-volume, uncompleted Start Header is also possible, if first volume was copied before end of archive (last volume) was written. In that case archive is not corrupted. And 7-Zip can unpack such archive, if total size is correct and if there is correct End Header.

If Start Header is OK, you can calculate correct archive size and compare with the size of archive that you have./

Наш случай по идее.

>>180563945
>Case: The end of archive is corrupted or missing.

Доктор, как много 2д-богинь мы уже потеряли?!

>>180564050
Нисколько, если всё правильно, потеряли только инфу про размер архива. Енд архива это всякая инфа служебная. Ща.

>>180564038
Так он же вродь не multi-value, а одиночный, не?

>>180564122
Хз, тогда не сходится что-то.

>>180564122
А, не, это типа если у тебя мультивольюм, то хуйня с нулями в стартхидере может быть нормой. Короче всё ок.

>>180564158
Ну в любом случае можно попробовать посчитать правильный размер архива, т.к. я в нем не уверен.

Но архивировалось точно без рабивки на части.

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

>>180564307
сейчас попробую

>>180564402
А лучше скачай 7Zipper на мобилу если не попрет с проводником

>>180564245
Короче, нужно создать будет архив, короче там по инструкции, стопудово наш случай.


Recover archive

We open bad.7z in hex editor

0000000000: 37 7A BC AF 27 1C 00 04 5B 38 BE F9 59 0E 00 00
0000000010: 00 00 00 00 23 00 00 00 00 00 00 00 7A 63 68 FD
0000000020: 00 21 16 89 6C 71 3D AB 7D 89 E6 3C 2E BE 60 24
We see that Start Header is OK.

We calculate correct archive size from Start Header fields values:

0x0E59 + 0x20 + 0x23 = 0x0E9C = 3740

Correct size is 3740 bytes, but our "bad.7z" is only 3000 bytes.

We look to the end of archive:

0000000B60: 55 73 EA 87 45 18 FC AD 67 0D 40 EF F4 41 49 63
0000000B70: 6A 87 54 70 32 6C B0 8F 76 2A 63 BF 12 5D 88 CD
0000000B80: 22 76 9F 97 05 3B 37 BE 49 CD F8 0A CC 67 FB FE
0000000B90: 17 2E 16 D5 1F 8C 5A 30 08 7F C6 E9 98 9F 00 F1
0000000BA0: A6 99 F9 ED 01 62 84 48 77 69 C7 65 21 21 42 66
0000000BB0: 48 F1 FE 79 06 08 25 68
And we don't see End Header at the end of archive.

Conclusion: archive probably was truncated.

Now we want to create another "good" 7z archive that contains good Start Header, End Header. and we want to place Compressed Data block from bad.7z inside that new "good" archive.

At first we look start of Compressed Data block in bad.7z:

0000000020: 00 21 16 89 6C 71 3D AB 7D 89 E6 3C 2E BE 60 24
If LZMA method was used, then first byte in compressed data is always 0 and high bit of second byte is also 0. So if we see 00 in first byte and from 00 to 7F in second byte, probably LZMA method was used (not LZMA2).

If first byte in compressed data is not 0 or if the value of second byte is higher then 7F, then it's not LZMA stream. It can be LZMA2 (or AES encrypted stream).

We must create new "good" 7z archive with same method as in bad.7z, and new archive must be much larger than bad.7z

So we select some big file for that new archive. In some cases you can use even bad.7z as that big file. But we use 7-zip.chm. We rename 7-zip.chm (91020 bytes) to file raw.dat and we compress raw.dat to raw.7z with LZMA method with big dictionary size value. The dictionary size must be equal or larger than dictionary size in bad.7z.

raw.7z is (84898 bytes) that is much larger than bad.7z, as required. if raw.7z is smaller than "bad.7z", you must create another raw.7z with another raw.dat that is larger.

We call "Split file..." function for bad.7z and type "32 100G" in "Split to volumes, bytes:" field.

It creates 2 parts:

bad.7z.001: 32 bytes : Start Header
bad.7z.002: 2968 bytes : start of Compressed Data
We call "Split file..." function for raw.7z and type "32 2968 100G" in "Split to volumes, bytes:" field. Note that the value 2968 is equal to size of "bad.7z.002". When you recover real archive, you must use exact size of your bad.7z.002.

It creates 3 parts:

raw.7z.001: 32 bytes : Start Header
raw.7z.002: 2968 bytes : start of Compressed Data
raw.7z.003: 81898 bytes : end of Compressed Data, Metadata Block, End Header
Then we rename bad.7z.002 file to raw.7z.002

Now multi-volume "raw.7z.*" archive contains good headers from raw.7z and compressed data from "bad.7z"

We press "Extact" for raw.7z.001 file. It will extract raw.dat file and probably it will show "Data Error" message.

Now we have raw.dat file that contains recovered stream from bad.7z.

Most of 7z archives are solid. If bad.7z archive was solid, then recovered stream consists of concatenated original files

If bad.7z archive is not solid, then recovered stream contains data for one file. It can also contain some garbage data at the end.

>>180564844
т.е. создать ахрхив большего размера, скопировать его хеадер в этот архив, а потом разбить этот архив на части?

>>180564844
>
>Conclusion: archive probably was truncated.
Вот как у нас. У нас получается вместо
>0x0E59 + 0x20 + 0x23 = 0x0E9C = 3740
0x5F59CEDE+0x32 = 0x5F59CF10

>>180564930
Да, итпа того, только внимательно делай всё, нужно указать тот же метод архивации, словарь большой юхать и тд.

>>180564930
Это ещё не всё, атм дальше тоже будет, но это сделай.

>>180565005
сейчас буду пробовать. Не помню что именно выбирал, но метод тыка - лучший способ все вспомнить

>>180565082
Нет, там написано, как узнать способ же.

>>180565124
>способ
Метод.

Ты только еще одну копию архива сделай, чтобы единственний экземпляр не пердолить

>>180565124
If LZMA method was used, then first byte in compressed data is always 0 and high bit of second byte is also 0. So if we see 00 in first byte and from 00 to 7F in second byte, probably LZMA method was used (not LZMA2).

>>180565082
Архив нужен гигов на 20.

>>180565211
У нас 28. Короче архивирй разными методами мелкие архивы, пока там не будет 28(это строчка номер 20).

>>180565338
ок

>>180565338
Оцй блы, наебао теья, всё ок, у нас стандартныйц, лзма короче.>>180565401
If LZMA method was used, then first byte in compressed data is always 0 and high bit of second byte is also 0. So if we see 00 in first byte and from 00 to 7F in second byte, probably LZMA method was used (not LZMA2).

If LZMA method was used, then first byte in compressed data is always 0 and high bit of second byte is also 0. So if we see 00 in first byte and from 00 to 7F in second byte, probably LZMA method was used (not LZMA2).

If LZMA method was used, then first byte in compressed data is always 0 and high bit of second byte is also 0. So if we see 00 in first byte and from 00 to 7F in second byte, probably LZMA method was used (not LZMA2).

>>180565401
всё ок!111 ниче не надо лхзма у нас

>>180565440
так, ок, теперь значит надо что-то на 20гб заархивировать?

>>180565496
Ну да, ща погоди, ещё перечитаю мб какие детали проебал.

>>180565534
ок, пока поищу файлы на 20гб

>>180565567
Пгоди он там какой 7-zip.chm юзает, может 7з может файлы генерить.

>>180565645
Хотя это просто апрхив изи файлы да. Пока читаю дохаваю.

>>180565708
Чекнул папку стима с играми - там как раз 17-25 гб будет

>>180565983
Так, я покушал, короче смотри, нужно даже больше, гигов 30-40, метод LSMA, размер словаря бери самый максимальный, он должен быть больше, чем у архива с няшками, поэтому чтобы наверняка побольше бери.

Сначала делаешь просто архив из этих 30-40 гигов, потом архив переименовывываешь в raw.dat, полученный файл архивируешь как выше сказал, скажешь сколько времени будет делаться.

>>180566195
>
>Сначала делаешь просто архив из этих 30-40 гигов,
Каким-нибудь зипом-хуипом, чтобы один файл получился как можно быстрее. А потом уже его переимоноываешь и сжимаешь как написал.

>>180566312
добавить к zip можно без сжатия или оно какое-нибудь должно быть?

>>180566759
Можно без, всё равно потом зип переименуешь.

>>180566759
Ну чё там? Сколько времени пишет займёт?

>>180566988
взял единственное хранилище файлов большого размера на пк - стим. Папку common, но чувствую что заебусь, сейчас попробую еще видосики просто надублировать в один ахрив, т.к. кажись это быстрее будет, чем перебор целой кучи файлов от игр.

>>180567149
> надублировать
Мда

>>180567149
Можешь текстовый файл сделать какой-нибудь. У тебя винда?

>>180567330
да, 10

>>180567366
(length is in bytes)
For example, to create a dummy file test.txt, with size as 50MB :

fsutil file createnew test.txt 52428800

Попробуй это. Создаётся файлик? Это нужно писать в cmd, либо можешь создать текстовый файл, вписать это туда, затем переименовать расширение на .bat и запустить.

> архив с сжатием
> сжимают нули
Мда хех

>>180567475
>fsutil file createnew test.txt 52428800
да, создался.
Сейчас гигов на 35 сделаю тогда.

>>180567621
Стой, это походе пустой файл, не так делай. Делай вот так

echo "This is just a sample line appended to create a big file.. " > dummy.txt
for /L %i in (1,1,24) do type dummy.txt >> dummy.txt

Это будет гиговый файл по идее. С текстом.

>>180567675
создался файл 1кб с текстом "This is just a sample line appended to create a big file.. "

>>180567763
Точно на кб? Попробуй 34 тогда.

Нахуй тебе 20 гигабайт, дебил обоссаный, тебе архив на 2 гига нужен.
Просто берёшь из `/dev/random` 2 гига и потом архивируешь.

>>180567812
Вместо 24.

Этого >>180567833 дауна не слушай. Делай по инструкции.

>>180567812
поставил 34 - то же самое

>>180567887
Это ты там нули в 2 гига сжимать предлагал?

>>180567917
Хм, ты точно всё правильно делаешь? По идее эта хуйня должна файл в степень возводить.

>>180568041
echo "This is just a sample line appended to create a big file.. " > dummy.txt
for /L %i in (1,1,34) do type dummy.txt >> dummy.txt

Земля пухом

111111

111111

>>180567966
>new archive must be much larger
В примере архив больше в 40 раз, анус ставишь, что в полтора раза будет достаточно?

>>180568081
Плюсую. Ему по факту нужно засунуть ~1.5гига сжатых файлов в другой сжатый архив и этот дебил создаёт архив в ДВАДЦАТЬ ГИГОВ, когда даже 2 гигов хватит с головой.

>>180568077
Я хуй знает, может потому что десятка.

>>180568077
Похуй ещё раз запусти, че будет?

>>180568077
Типа файл не удаляй, который в 1 кб.

>>180568283
крч я нагуглил как сделать то, что ты хотел. Сейчас создался файл текстовый размером 1гб (могу и больше, если надо)

>>180568151
Ну так и следуй тутору, там ведь good.7z аж на 84898 байт больше, чем bad.7z

>>180568077
Хотя бля, не делай этого, вдруг пизданёт ещё, весь жёсткий засрётся, напиши так мб

for /L %i in (1,1,4096) do type "x" >> dummy.txt
Должно быть 4кб по идее?

>>180568414
Щас сожмешь и получишь пару сотен килобайт, если не меньше.

>>180568454
не, я уже сделал файл на 1гб )

>>180568485
Заебись, делай на 40. Хотя вот тот анон говорит, что типа больше не В а На. Ну попробуй ебани 2 гига. Если сожмётся в хуйню, то заархивируй чета нормальное,а не чучело типа.

>>180568572
Да его мусорный текстовый файл сейчас в сожмётся на раз и будет у него архив размером в сотню килобайт.

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

Ну что там ребяты? Когда богинь раздавать начнут?

>>180568755
Там про это ничего не сказано, сказано про словарь и метод только. Похуй, жми! Жми, братан!

>>180568750
У тебя просто английский в деревне не преподают, вот и не понимаешь, о чем там написано.

>>180568755
Тока потоки поставь 8.

>>180568833
Не, нихуя, это ты думаешь, что у тебя преподают, там написано Чем, а не На.

>>180568873
Долбоёб, там нихуя не написано о том, во сколько или на сколько раз архив должен быть больше.
Там вообще написано, что можно использовать тот же битый архив.

>>180568755
Настройки должны быть такими же, какие у битого архива.

>>180568833
Я вот ща перечитал и чувствую, что нихуя не выйдет
>>180568945
Там между строк написано. Вот жопой чую, что надо было больше делать, а ты пидор меня сбил своей хуйнёй, влез бля умник хуев. Ща вот посмотрим.

>>180569002
Какие блядь "между строчек"? Это тебе не художественная литература.
In some cases you can use even bad.7z as that big file.

>>180569112
Архив должен быть гораздо больше, чем исходный файл. Тут вот в гораздо между строчек зашифровано в. А не на.

>>180568755
Ну чё там? Как оно?

>>180569299
так, крч запилил .zip в восемь потоков без сжатия.
или сразу в 7z пилить? Но там LZMA не дает 8 потоков ставить.

Или рил мб заархивировать битый архив?

>>180569400
Переименуй zip в raw.dat и ебашь в 7z, словарь макс, сжатие lzma, остальное похуй.

>>180569400
>
>Или рил мб заархивировать битый архив?
Нет.

>>180569236
Земля тебе пухом, лучше бы ты продолжал 'хакать' игры через cheat engine

>>180569551
Ты какой-то дурачок со сломанным детектором и комплексом комплексов. Иди своей дорогой уже, отвлекаешь.

>>180569400
good.7z должен быть в формате 7z, zip и 7z разные форматы.

>>180569625
Это предварительный файл, его просто переименовать и заархивировать, вот зачем лезешь, отвлекаешь анона?

>>180569613
Продолжай искать 'шифры между строчек' в технической документации.

>>180569722
Хорошо. Щас бы туториал технической документацией называть.

>>180569400
Ну как оно? Долго будет?

>>180569400
Я курить пока что.

>>180569815
Хз, чёт ноут затупил, сча перезагружать скажу чё как

Оп, а ты как собираешься файлы разделять потом? Тебе ведь на выход даст просто поток байт. Фоточки придётся по 1 из этого потока доставать.

>>180569994
Там дальше в инструкции описано всё.

>>180569815
Готово, но размер архива этого .datфайла вышел 300кб

>>180571043
Плохо, надо значит брать реальные файлы. Папку steam и тп.

>>180571109
У меня ноут умрет эту дичь архивировать, да и времени явно прилично займет, так что хз даж

>>180571043
Ха-ха, как я и говорил.
>>180568717
Сжимай bad.7z свойразмер получившегося архива должен быть на пару сотен килобайт больше bad.7z, чтоб наверняка влезло

>>180571109
Хотя если надо чтобы на выходе был 2 Гб архив, то вполне реально, но при максимальном размере словаря ноут тож тупит дико пока архивирует в 7z

Блен, попробуй на мобилу скачать 7Zipper. Может архив себя на андроиде будет лучше вести

>>180571254
А ты как думаешь, сколько словарь ставить? Максималка?

>>180571202
Тогда поставь на ночь, дальше по инструкции сделаешь, только там нужно будет разбить на архивы с определённым размером, размер выставь


We call "Split file..." function for bad.7z and type "32 100G" in "Split to volumes, bytes:" field.

It creates 2 parts:

bad.7z.001: 32 bytes : Start Header
bad.7z.002: 2968 bytes : start of Compressed Data
We call "Split file..." function for raw.7z and type "32 2968 100G" in "Split to volumes, bytes:" field. Note that the value 2968 is equal to size of "bad.7z.002". When you recover real archive, you must use exact size of your bad.7z.002.

It creates 3 parts:

raw.7z.001: 32 bytes : Start Header
raw.7z.002: 2968 bytes : start of Compressed Data
raw.7z.003: 81898 bytes : end of Compressed Data, Metadata Block, End Header

Где жирным отметил должен быть размер такой:
1599721214 запиши где нибудь.

>>180571341
Тож попробую, попытка не пытка

>>180571202
Ещё в теории можно полученный архив скопировать N раз и засунуть в папку всё это говно, а папку заархивировать, он уже меньше не сожмётся, может гораздо быстрее будет.

>>180571254
> как я и говорил.
>. Если сожмётся в хуйню, то заархивируй чета нормальное
Какой ты умный, пиздец просто.

>>180571476
Го попробуем с плохим архивом, сжатым lzma

>>180571831
Попробуй, но мне кажется размер не сработает, размер меньше будет по любому, хотя хуй знает, с другой стороны может и сработает, типа допишется только служебная инфа. Но хз.

>>180571831
Ещё можешь скинуть мне файл и почту. Файл можешь залить сюда, например.
https://dropmefiles.com/

>>180571341
Пробывал ?

Или же на яндекс диск залей

>>180572648
Сейчас попробую сделать все по инструкции с тем же файлом заархивированным. Если не получится - тогда уже залью куда-нибудь. На всякий случай мой телеграм @n1ghtman, а то мало ли

>>180573729
Окей, напишу, я пока тут одну хуйню пишу, похоже она понадобится, когда raw file получишь.

>>180573729
А через мобилу пробывал ?

>>180573848
Нет.

>>180573900
Попробуй

>>180574013
У меня нет мобилы.

>>180574066
что?)

>>180574096
Вот так вот.

>>180573819
ну крч кое-что все же вытащил, сейчас поиграюсь еще, мб вытащу что еще )

>>180574222
Что вытащил? Архивы? Я пишу прогу, которая парсит raw file на тему jpg и вытаскивает их сейчас.

>>180574222
так кидай фотки, что вытощил

>>180574278
вытащил фотки, причем все из одной папки, которая там была. Больше ничего. Файл .dat показывает 836 мб размер, когда открыл как архив - показал 30 пикч. Сейчас буду пробовать разные настройки архиватору ставить чтобы заголовки другие получились, мб больше вытащу.

>>180574844
Ок, там написано, что 7zip овский парсер рав файла видит только архивы, папки и тп, возможно там все пикчи в одной папке лежат, файлы он не видит, надо писать прогу, вот сейчас пишу, слил три жипега в один, должна прога их разделить.

>>180574844
Ты только файл этот схорони дат обязательно.

>>180575104
ок

>>180575119
Ещё возможно, что тут хуй наебал и действительно надо 30 гигов. Типа затёрлось одно другим. Но я хз, я точно так же как и ты на ходу это всё узнаю.

>>180575143
Тогда на всякий попробую еще с архивом побольше потом