Программы


Ответить в тред Ответить в тред

Check this out!
<<
Назад | Вниз | Каталог | Обновить тред | Автообновление
61 7 37

Двач, восстановление файлов = миф? Проебал архив, Аноним (Microsoft Windows 8: Firefox based) 26/01/20 Вск 16:36:09 27258891
Image-25.jpg (19Кб, 594x478)
594x478
Двач, восстановление файлов = миф? Проебал архив, восстановил Recuva, архив не открывается
Если там нет инфы на годовую зарплату, проще забить нахуй?
Аноним (Fedora Linux: Firefox based) 26/01/20 Вск 16:39:40 27258932
>>2725889 (OP)
В WinRAR есть опция восстановления архивов.
Аноним (Microsoft Windows 8: Firefox based) 26/01/20 Вск 16:41:23 27258953
Аноним (Google Android: Mobile Safari) 26/01/20 Вск 16:43:57 27258994
>>2725889 (OP)
Это не миф, просто гарантий никаких.
Аноним (Fedora Linux: Firefox based) 26/01/20 Вск 16:44:56 27259015
>>2725895
Не знаю, пробуй. Если нет избыточности, то скорее всего удалит повреждённые файлы и оставит целые. Хоть что-то вытащишь.
Аноним (Fedora Linux: Firefox based) 27/01/20 Пнд 13:25:49 27261816
Аноним (Microsoft Windows 8: Firefox based) 28/01/20 Втр 00:09:22 27264377
>>2726181
Знаешь, забил болт, ибо нашел нужный документ в кэше
Пробовал разными прогами, находит только не нужные мне файлы, а то что нужно нет
Короче, далеко не все можно восстановить
Аноним (Google Android: Mobile Safari) 30/01/20 Чтв 22:37:14 27278058
Можно восстановить документ, который был в общей папке на сервере ?
Аноним (Google Android: Mobile Safari) 30/01/20 Чтв 23:36:52 27278279
Herman recovery неплохо восстанавливает архивы
Аноним (Microsoft Windows 7: Chromium based) 30/01/20 Чтв 23:39:51 272782810
image.png (434Кб, 488x626)
488x626
Люди делятся на 3 категории: те кто еще не делает бэкапы, те, кто уже делает бэкапы, и тех, кто уже делает и проверяет возможность восстановления.
Аноним (Microsoft Windows 8: Firefox based) 01/02/20 Суб 00:41:48 272822811
>>2727828
Они обычно настолько старые, что уже не представляют ценности)
Аноним (Microsoft Windows 10: Firefox based) 01/02/20 Суб 10:37:36 272833312
>>2725889 (OP)
Сразу чёт вспомнил рарохейтеров с "да никому не нужна информация для восстановления @ да fault-tolerance архитектура для дебилов, кому нужен наполовину восстановленный архив @ да все же бэкапы делают @ 7z наше всё @ основная задача архива сжимать @ отказоустойчивость на par2 реализуем".
Первичная задача архиватора - надёжно хранить файлы. Экономия места вторична. Любой современный архиватор обязан уметь в коррекцию ошибок изкоробки, потому что задумываются об этом уже когда надо восстанавливать.
Аноним (Microsoft Windows 10: Firefox based) 01/02/20 Суб 10:41:11 272833413
>>2725901
> .zip
> удалит повреждённые файлы и оставит целые
У зипа непрерывный поток, если есть мусор в начале, то дальше ошибка будет только накапливаться и ничего не восстановит.
Аноним (Microsoft Windows 10: Chromium based) 01/02/20 Суб 20:35:22 272861114
Аноним (Microsoft Windows 10: Chromium based) 01/02/20 Суб 21:24:09 272862715
>>2725889 (OP)
Хуй ты что восстановишь, если место, где лежал удалённый файл, уже было перезаписано.
/thread
Аноним (Microsoft Windows 7: Chromium based) 02/02/20 Вск 01:19:05 272870116
>>2728228
Ну так чаще надо делать =)
Аноним (Google Android: Mobile Safari) 02/02/20 Вск 01:26:03 272870317
Отечественные варианты есть какие-то? Не гуглится.
Аноним (Неизвестно: Неизвестно) 03/02/20 Пнд 02:42:03 272935918
>>2728703
>Отечественные варианты
+15
Аноним (Microsoft Windows 7: Firefox based) 07/02/20 Птн 17:54:22 273171919
>>2728333
7zip к сожалению и правда во многих отношения выглядит удобнее - у винрар одно преимущество, которое ты назвал - безопасность.
С другой стороны, добавляя информацию для восстановления к каждому архиву, чувствую себя аутистом, учитывая, что из всех когда-либо созданных мной архивов, повреждался только один и когда-то очень давно, а может это мне вообще приснилось. Хз, по-моему легче всю важную информацию тупо дублировать на отдельный носитель - рейд там хуейд, хз как это лучше реализовывать.

>>2725889 (OP)
r-studio уже называли - хорошая программа. hetman partition recovery тоже хорошо себя показала.
Наиболее эффективный тип восстановления - это всегда полное сканирование поверности диска, это отдельный режим и там нельзя ни разделов ничего вообще выбирать. В hetman такое точно есть, в r-studio тоже должно быть. А вот recuva это так, поиграться.
Аноним (Apple Mac: Яндекс браузер) 07/02/20 Птн 18:01:30 273172620
>>2731719
>А вот recuva это так, поиграться.
Вообще-то наоборот. Recuva нужна постоянно, удалил файл нечаянно и спохватился - recuva быстро и легко восстановит. А катастрофы с целыми дисками, когда нужны R-Studio и т. п., возникают только раз или два в жизни.
Аноним (Microsoft Windows 7: Firefox based) 07/02/20 Птн 18:40:08 273175921
>>2731726
Не выебывайся, ты понял о чем я.
Аноним (Microsoft Windows 10: Chromium based) 09/02/20 Вск 08:08:35 273265422
Аноним (Microsoft Windows 7: Firefox based) 09/02/20 Вск 09:38:06 273267223
>>2731719
>Хз, по-моему легче всю важную информацию тупо дублировать на отдельный носитель - рейд там хуейд, хз как это лучше реализовывать.
ZFS внезапно сжатие на уровне фс.

>>2728333
Чушь какая.
Изначально архиваторы нужны были для экономии места, а в 2020 это просто контейнеры для файлов, и всяких инсталяторов/пакетов.
Информация для восстановления нужна была во времена ДИСКЕТ и 20МБ винчестеров, когда блоки данных постоянно проёбывались.
Сейчас и в винчестерах и в ССД ебучие как суки алгоритмы коррекции по сравнению с которыми винрар просто детская игрушка.
Аноним (Microsoft Windows 10: Chromium based) 10/02/20 Пнд 22:20:47 273353024
>>2732672
>пук среньк сжатие
Было в NTFS в 1993 году, есть и сейчас, хотя им никто не пользуется.
Но зачем жму/дебилоидам такие тонкости?
Аноним (Apple Mac: Яндекс браузер) 11/02/20 Втр 01:26:41 273362325
>>2728333
>>отказоустойчивость на par2 реализуем
Святая мудрость. Дебилам вроде тебя не понять насколько ахуенно удобно и реально полезно когда инфа для восстановления в отдельных файлах и отдельная программа этим занимается. Раропараша вообще бесполезна, больше рекламная функция для галочки.
Аноним (Microsoft Windows 8: Firefox based) 11/02/20 Втр 10:34:43 273368726
>>2725889 (OP)
>Проебал архив, восстановил Recuva, архив не открывается

Потому что ты проебал архив, даун, если бы ты проебал просто файлик, все было бы норм
Аноним (Microsoft Windows 8: Firefox based) 11/02/20 Втр 10:36:12 273368827
>>2727828

щас бы всякий мусор бэкапить

мимо-складирую-шебмки-на-сервера-с-tahoelafs
Аноним (Linux: Firefox based) 11/02/20 Втр 11:19:51 273369128
>>2731719
>добавляя информацию для восстановления к каждому архиву, чувствую себя аутистом
Для фикса битрота достаточно 2%. От пресетов сжатия разброс в итоговом файле и то больше.
Да и больше мне печёт от отсутствия отказоустойчивой архитектуры, она-то ничего не жрёт. Если бы в дефолтном зипе, который юзается во всяких docx, был реализован fault-tolerance, как в раре, то цивилизация сохранила бы сотни тысяч сфинктеров. Нет ведь, одна ошибка и весь архив по пизде. И 7zip на эти же грабли с размаху наступает.
Аноним (Linux: Firefox based) 11/02/20 Втр 11:43:23 273369329
изображение.png (19Кб, 255x229)
255x229
>>2732672
>Изначально архиваторы нужны были для экономии места
Ты путаешь архиваторы и компрессоры.
Изначально архиваторы занимались сериализацией ФС для записи на ленты. Сжатие появилось позднее, когда ЦП подросли.

> в винчестерах
Официально заявленная производителем вероятность битовой ошибки - 1e-14. В среднем один битый архив на 10Тб данных. Бытовые ФС не умеют их корректировать. Это ещё на сцену бэды не вышли.

> Сейчас
А сейчас ты видишь боль опхуя, и в диких джунглях айтимакак это максимально распространённый сценарий. Ты можешь заботливо бэкапировать всё что видишь, но восстанавливать приходить ебать какую редкую таблицу с флешки нинивановны, от которой зависит судьба всего предприятия.
Отказоустойчивость должна дублироваться на всех слоях. Отказоустойчивость должна быть включена везде подефолту. Отказоустойчивость никогда не может быть избыточна. Ты должен совершить осознанное действие чтобы отключить дефолтную отказоустойчивость ради экономии 2-3% места.
Аноним (Microsoft Windows 7: Firefox based) 19/02/20 Срд 03:27:19 273767830
>>2733691
>Да и больше мне печёт от отсутствия отказоустойчивой архитектуры, она-то ничего не жрёт. Если бы в дефолтном зипе, который юзается во всяких docx, был реализован fault-tolerance, как в раре, то цивилизация сохранила бы сотни тысяч сфинктеров.
А что за отказоустойчивая архитектура, и почему она не занимает доп. места?
Аноним (Linux: Firefox based) 19/02/20 Срд 09:52:16 273773831
Предлагаю раз и навсегда закрыть вопрос об «Информации для восстановления» в архивах RAR (см. влажные фантазии в >>2725893>>2728333>>2731719>>2733691). Также предлагаю сделать из этого поста пасту, чтобы регулярно напоминать жадным детям о том, что у WinRAR ощутимого преимущества нет.

1. Когда мы говорим о надёжности систем обработки, передачи и хранения информации, нужно постоянно держать в голове, что ещё в начале прошлого века Шеннон сформулировал термодинамические основы теории информации, в соответствии с которыми в замкнутой системе информация разрушается. Всегда. Без исключений. Чуть позже тот же Шеннон определил для каналов с АБГШ теоретические пределы помехоустойчивости. А ещё чуть позже с теми же помехами были определены другими исследователями т. н. «пределы Шеннона» и для помехоустойчивого кодирования. Реальные системы к ним могут только приближаться. Причём, чем ближе вы к пределу Шеннона, тем больше ресурсов (например, избыточности) будет требоваться на каждый следующих шаг уменьшения апостериорной вероятности битовой ошибки. Для желающих погрузиться в увлекательный мир теории информации с полями Галуа и пространством Хемминга, разумеется, рекомендую начать с книжки Р. Галагера «Теория информации и надёжная связь» (перевод, Советское радио, 1974 г.).

2. Современные HDD и SSD предоставляют благодаря встроенному помехоустойчивому кодированию апостериорную вероятность битовой ошибки порядка 10−14. Для сравнения, вероятность ошибок при работе ECC-памяти (а вы на практике собираетесь в большинстве случаев читать, записывать и копировать через обычную память, с которой всё ещё хуже, лол) оценивается в пределах от 2,5×10−11 до 7×10−11 битовых ошибок в час, см. http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

3. Что же предлагает нам WinRAR|RAR? Алгоритм, который уменьшает апостериорную вероятность битовых ошибок на хуйзнаетсколько всего за $9,99 2% избыточности (будем для краткости называть это алгоритмом Касьянова-Рошала).

4. А что же предлагают настоящие промышленно применяемые алгоритмы помехоустойчивого кодирования? Нетрудно увидеть на с. 17 вот этой диссертации https://backend.orbit.dtu.dk/ws/portalfiles/portal/103383788/PhD_thesis_boml..PDF
Там рассматривается итоговая апостериорная вероятность битовых ошибок порядка 10−15, т. к. её на практике отделяет всего один порядок от реально достижимого дна, рассмотренного в статье https://arxiv.org/pdf/1208.1326.pdf
Так вот, там избыточность алгоритмов лежит в пределах от 6,7 до 25%.

5. Тут впору подумать об алгоритме Касьянова-Рошала, что есть два стула варианта:
- либо разработчики WinRAR поймали бога за бороду охуительное открытие, незамеченное специалистами;
- либо эффективность алгоритма Касьянова-Рошала реально почувствовать только на 3-дюймовых дискетах канале с очень высокой (порядка 10−4...10−8) вероятностью ошибок.
На всякий случай, расскажу, что каскадирование помехоустойчивых кодов в литературе называется турбокодами. И эффективность такой схемы растёт хотя бы в разы (при росте избыточность в тоже разы, лол) при сравнимой (хотя бы того же порядка) эффективности всех звеньев. Т. е. ожидать снижения апостериорной вероятности битовой ошибки с 10−14 до 10−15 при обмазывании алгоритмом Касьянова-Рошала поверх того, что уже встроено в HDD|SSD не приходится.
Такие дела. Наиболее вероятно, что «Информация для восстановления» является не более, чем мнимым преимуществом, обеспечивающим коммерческую привлекательность, но не реальную эффективность на современных каналах связи и носителях.


А теперь по треду пройдёмся.

>>2725889 (OP)
> Двач, восстановление файлов = миф?
Нет.

> Если там нет инфы на годовую зарплату, проще забить нахуй?
Да.

> Проебал архив, восстановил
Резервные копии (на других носителях и в других вычислительных машинах). На сегодня только так.

> Короче, далеко не все можно восстановить
Вот это открытие. А завтра ты поймёшь, что в лотерейные билеты и рулетку деньги вкладывать нельзя?

>>2727828>>2733623

Да, всё так.

>>2728334
> У зипа непрерывный поток
Нет.

>>2732672
> Сейчас и в винчестерах и в ССД ебучие как суки алгоритмы коррекции
Да.

> по сравнению с которыми винрар просто детская игрушка
Да.

>>2733693
> вероятность битовой ошибки - 1e-14
> Это ещё на сцену бэды не вышли.
Что там бэды? Столь малые вероятности ошибок упрутся уже в ECC-память (даже не в обычную).

>>2737678
Очевидно же — Волшебная. Из того же магического мирка розовых пони в котором у >>2729359
светом истины сияет Маэстро, а цивилизация светлых эльфов у >>2733691 «сохраняет сотни тысяч сфинктеров путём повсеместной реализации fault-tolerance как в раре». Вот же влажность-то.
Аноним (Ubuntu Linux: Firefox based) 19/02/20 Срд 14:40:47 273782532
>>2737738
Чувак, я вообще мимо-проходил в поисках на двачах годного легковесного браузера под убунту, но начал читать твой пост... это ахуенно, бладж.
понял примерно половину, но теперь пойду гуглить из любопытства. Спасибо.
Аноним (Microsoft Windows 7: Firefox based) 19/02/20 Срд 15:16:20 273784633
>>2737738
Напиши более простым языком. Так как ты, используя все эти термины и перечисляя фамилии, подразумеваешь, что ты умен и начинат, то у тебя должно хватить ума, чтобы: 1.понять, что людям, которые не знают всего того, о чем ты пишешь, нужно объяснять все это языком по-проще 2. объяснить все это так, чтобы у не знающих людей не возникало сложностей с пониманием написаного

Потом, ты пишешь про избыточность в 25%, но в винраре можно хоть 100% избыточность выставить, какие вообще проблемы.

>либо эффективность алгоритма Касьянова-Рошала реально почувствовать только на 3-дюймовых дискетах канале с очень высокой (порядка 10−4...10−8) вероятностью ошибок.
Вот этого тоже не понял. Вроде ты с одной стороны написал, что 2% мало, с другой пишешь, что 2% имеет смысл только на канале с очень высокой вероятностью ошибок, хотя логично, что если в случае с высокой вероятностью ошибок, 2% может принести пользу, то с низкой вероятностью таковых, 2% могут принести пользу тем более.

>Т. е. ожидать снижения апостериорной вероятности битовой ошибки с 10−14 до 10−15 при обмазывании алгоритмом Касьянова-Рошала поверх того, что уже встроено в HDD|SSD не приходится.
Ты не написал ничего убедительного против полезности информации для восстановления в случае с бедами.

>Святая мудрость. Дебилам вроде тебя не понять насколько ахуенно удобно и реально полезно когда инфа для восстановления в отдельных файлах и отдельная программа этим занимается. Раропараша вообще бесполезна, больше рекламная функция для галочки.
Здорово, но ты не всегда можешь контролировать подобные вещи - например, если архив будет храниться не под твоим контролем, а на чужом хранилище и тебе нужно позабоиться о том, чтобы данные были сохранны наверняка. Чтобы архив, отправленный в дальнее плавание, точно был отказоустойчив. Или когда у тебя нет времени пока что морочиться с установкой всех этих систем восстановления данных, а архив устойчивым нужно сделать прямо сейчас и конкретно этот.

В целом не слишком убедительный пост. Напоминает ситуацию, когда в теории то все заебись, а вот на практике пользователи часто встречаются с проблемами, которых в теории быть не должно, и в данном случае это теоретически будет означать, что данные для восстановления, пусть и небольшие, действительно могут приносить пользу.
Аноним (Linux: Firefox based) 19/02/20 Срд 16:14:03 273788634
>>2737738
Это ты ловко передвинул вопрос из качественной в количественную плоскость. Мол, глядите не 1е-14, а 1е-15, какая разница?
А разница в том, что после стечения всех обстоятельств ты сможешь восстановить файл не с вероятностью 1/20, а с 1/2.

Да и тезис изначально ставился не как "в раре такие классные корректирующие коды", а "почему опенсорсные архиваторы до сих пор не умеет корректирующие коды".
Аноним (Linux: Firefox based) 20/02/20 Чтв 01:52:44 273816635
ber-vs-ebn0-bpsk.png (25Кб, 836x451)
836x451
>>2737846
> Напиши более простым языком.
В геометрию «царского пути» нет. Но кое-что пояснить можно на пальцах.

> подразумеваешь, что ты умен и начитан
Именно по этой причине я даю ссылки на источники.
Чтобы вы тоже могли такими стать.

> объяснять все это языком по-проще
Суть помехоустойчивого кодирования заключается в том, чтобы распределить информацию в пространстве и времени таким образом, чтобы канальный шум, распределённый вовсе не таким образом, можно было легко отличить, а, если повезёт, то и компенсировать.
Поясню на примере. Есть у тебя три соединённых друг за другом «чёрных ящика»: кодер, канал передачи и декодер. У двух ящиков есть по одной ручке, которую можно крутить на увеличение и на уменьшение, у третьего — только индикатор:
- у кодера можно крутить избыточность (отношение ширины потока данных в канале к ширене потока данных полезной нагрузки, минус единица ещё);
- у канала можно крутить относительную интенсивность помехи (например, через отношение энергии полезного сигнала к энергии помехи/шума);
- у декодера можно только посмотреть на индикатор счётчика ошибочных бит.

Если покрутить туда-сюда ручку «отношение сигнал/шум», то можно по отметкам вероятности ошибок построить график как на прикреплённом рисунке. Смею надеяться, не нужно объяснять, почему с увеличением соотношения сигнал/шум вероятность битовых ошибок падает. Для сравнения показаны начальные участки характеристик для некодированной двухпозиционной фазовой манипуляции и для кодированной свёрточными кодами (14,3%), кодом Хемминга (75%), кодом Голея (100%) и кодом Рида-Соломона (6,7%). В скобках указана избыточность. Лучше точки, которые леве и ниже. Если измерять между графиками расстояние по горизонтали, то это будет энергетический выигрыш (фактически компенсация энергии шума за счёт кодирования); если измерять по вертикали — то выигрыш будет в вероятности ошибки (т. е. насколько связь будет надёжнее при том же уровне помех в канале).

И вот тут пришло время поглядеть на рисунок 2.1 в упомянутой диссертации, на котором по вертикали отложен энергетический выигрыш, а по горизонтали — избыточность. На нем показаны точками характеристики помехоустойчивых кодов, преимущественно приведённых к выходной вероятности ошибки 10−15. Чтобы можно было проследить не только связь энергетической эффективности и избыточности, что какбэ намекает, что с двумя процентами алгоритму Касьянова-Рошала на таких графиках, скорее всего, и делать-то нечего. Кроме того, чтобы можно было проследить эволюцию методов кодирования, отложены три поколения кодеков: перовое появилось ещё в 1960 году, второе промышленно освоено в нулевых, третье — это последний писк науки-техники, поставленный на промышленные рельсы в десятых (ну, и, как водится, первые турбо-коды придуманы в 1993 году).

А вот теперь самая приятная вишенка. Ищем в упомянутой диссертации страницу 9, находим на ней рисунок 1.5, на котором по горизонтали отложена входная вероятность ошибок (до коробочки декодера), а по вертикали — выходная (т. е. после декодера). График дан для иллюстрации энергетического выигрыша при применении помехоустойчивого кодирования, но самое интересное на нём — это шумовое донце («error floor»). Вся мякотка в том, что, какая бы ни была вычислительная техника, она не в состоянии это дно пробить никакими программными или структурными ухищрениями. Разгадка кроется в упомянутых в >>2737738 физических ограничениях электронной компонентной базы. Вот и выходит, что при достаточно эффективном кодере (это про показанные на рисунке 2.1, а не про алгоритм Касьянова-Рошала), уже при первичных ошибках канала порядка 10−4...10−3 (примерное отношение сигнал/шум по прикрепленному рисунку от 7 до 8,5 дБ) нормальный-то кодер уже упрётся в шумовое дно на выходе под 10−18 и дальнейшее усложнение кодера будет только повышать ошибку. Если вы диссертацию ещё немного почитаете, то узнаете, что уровень 10−18 — это предел, возможно достижимый ПЛИСами со статической памятью, а с нашим родным ПО (да с динамической-то памятью) и 10−15 будет не всегда доступно.

>>2737846
> Потом, ты пишешь про избыточность в 25%, но в винраре можно хоть 100% избыточность выставить, какие вообще проблемы.
Идём сюда https://www.rarlab.com/rarnew.htm и читаем:
> RAR 5.0 recovery record is based on Reed-Solomon error correction codes.
> We used "Screaming Fast Galois Field Arithmetic Using Intel SIMD Instructions"
Отлично. В 5-ой версии алгоритм Касьянова-Рошала наконец-то заменили на каскадное кодирование с Ридом-Соломоном, как в http://dx.doi.org/10.1109/18.6025 и https://arxiv.org/pdf/1503.05477.pdf
Проблемы в том, что HDD|SSD уже дали тебе вероятность 10−14. Спуститься до дна в 10−15 можно, но смысла уже нет.

> 2% имеет смысл только на канале с очень высокой вероятностью ошибок
Чтобы сделать 10−8 из 10−5, не более того.

> в случае с высокой вероятностью ошибок, 2% может принести пользу, то с низкой вероятностью таковых, 2% могут принести пользу тем более
Так падающий возврат есть. Хорошее улучшить сложнее, чем плохое. Смотрим ещё разок рисунок 1.5: сначала у кодера эффективность прёт почти вертикально, а потом, по мере снижения числа ошибок в первичном канале, начинает уменьшаться.

> Ты не написал ничего убедительного против полезности информации для восстановления в случае с бедами.
Так общими словами оно в документации к RAR 5.0 описано уже (до этого поста я не её читал ещё). У них там перемежитель (такой ящик, который перемешивает блоки из сжатого потока данных в адресном пространстве, чтобы один сравнительно длинный повреждённый кусок файла был раскидан по потоку более мелкими ошибками, для которых шанс на исправление выше), судя по написанному, есть. Должно помогать. Но импульсные помехи — это не АБГШ, они нестационарные, я бы не взялся прикинуть эффективность.

> Или когда у тебя нет времени пока что морочиться с установкой всех этих систем восстановления данных, а архив устойчивым нужно сделать прямо сейчас и конкретно этот.
Отдельный файл сильно лучше, т. к. его можно по другому каналу доставить. Единственная, конечно, вещь, которая пока в RAR перспективной остаётся — это перемежитель. Но это если только нет соответствующего отдельного ПО, в чём я сомневаюсь. А так-то да. Соглашусь, что из плохих способов обеспечения надёжности передачи файлов с сжатых контейнерах RAR является, скорее всего, лучшим.

> В целом не слишком убедительный пост.
> Напоминает ситуацию, когда в теории то все заебись, а вот на практике
Обычно в таких случаях я рекомендую оппоненту на практике испытать прочность законов физики, действующих в наблюдаемой части вселенной. Иначе говоря, предлагаю пойти и удариться головой о бетонный блок. Я привёл ссылки на практические исследования на аппаратной базе. Тру по ссылкам не ходят, но всё же.

>>2737886
> Это ты ловко передвинул вопрос из качественной в количественную плоскость.
Ещё один не знает законов в наблюдаемой вселенной. Иди три закона диалектики повтори!

> Мол, глядите не 1е-14, а 1е-15, какая разница?
Уверенно об этой разнице можно будет сказать только после 1017 переданных и проверенных бит. На настольных пеках, скорее всего, тебе этого не даст сделать динамическая память.

> А разница в том, что после стечения всех обстоятельств ты сможешь восстановить файл не с вероятностью 1/20, а с 1/2.
При каскадировании помехоустойчивых кодов вероятности не перемножаются. См. http://dx.doi.org/10.1109/18.6025

> Да и тезис изначально ставился не как "в раре такие классные корректирующие коды"
А они классные. Да только я пруфы нашёл сам, что, разумеется, к твоему стыду.

> а "почему опенсорсные архиваторы до сих пор не умеет корректирующие коды"
Потому, что:
- юникс-вей — архиватор отдельно, энтропийный кодер отдельно, перемежитель отдельно, помехоустойчивый кодер отдельно;
- 3-дюймовые дискеты уже давно в прошлом — носители и сетевые протоколы оснащены сегодня штуками по-круче, чем кодер Рида-Соломона.
Что же касается мокренького 7-zip, то, да, ему бы неплохо обзавестись помехоустойчивым кодером и перемежителем, но это надо обратную совместимость нарушать, да и нет в планах такого (просят с 2003-его года, лол).
А так есть и par2 и zfec, но нет перемежителя.
Аноним (Linux: Firefox based) 20/02/20 Чтв 02:11:34 273816936
>>2738166
>Что же касается мокренького 7-zip, то, да, ему бы неплохо обзавестись помехоустойчивым кодером и перемежителем, но это надо обратную совместимость нарушать, да и нет в планах такого (просят с 2003-его года, лол).
>А так есть и par2 и zfec, но нет перемежителя.
Как я писал где-то выше, просто нет в этом никакого смысла, не востребовано абсолютно.
Системы кодирования встроены всюду, от железа жестких дисков и процессоров, рейд контроллеров, сетевых карт, до файловых систем, вроде ZFS.
Аноним (Linux: Firefox based) 20/02/20 Чтв 02:23:03 273817037
>>2733693
>Отказоустойчивость никогда не может быть избыточна
Может, выше написали как и почему.

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

>Ты должен совершить осознанное действие
Никогда не использовать винрар и вообще сжатие.

>Ты путаешь архиваторы и компрессоры.
Да, спасибо за экскурс в историю.
Сейчас, кстати, устройства записи на ленту используют свое нескучное сжатие и йоба кодирование для защиты от ошибок.
Аноним (Linux: Firefox based) 20/02/20 Чтв 10:43:15 273823138
>>2738169
>Системы кодирования встроены всюду, от железа жестких дисков и процессоров, рейд контроллеров, сетевых карт, до файловых систем, вроде ZFS.
В типичном стэке Марьистепанны, где стратегически важные данные в едином экземпляре по умолчанию пожаты в zip и лежат в FAT32 на китайской нонейм флешке, нет ни одного слоя коррекции ошибок. Дай бог в контроллере флешки.
Не надо проецировать свой радужный мир пони на всех остальных. Действительность - невероятно суровая штука.

>>2738170
>Лучше сделать несколько копий
Ещё раз. Отказоустойчивость задним числом не обеспечишь. Именно вот этот самый нужный файл окажется в единственном экземпляре. Потому что "места не хватало, я лишние файлы и удалила".
>Никогда не использовать сжатие.
О docx слышал?
Аноним (Microsoft Windows 10: Firefox based) 20/02/20 Чтв 10:51:40 273823639
>>2738170
>Никогда не использовать винрар и вообще сжатие.
RAR это архив с избыточной информацией для восстановления, в отличии от. Просто не все юзают функцию.
Аноним (Linux: Firefox based) 20/02/20 Чтв 11:28:22 273824640
>>2738231
> В типичном стэке Марьистепанны
> стратегически важные данные в едином экземпляре по умолчанию пожаты в zip и лежат в FAT32 на китайской нонейм флешке
> нет ни одного слоя коррекции ошибок. Дай бог в контроллере флешки.
Так тут RAR-то не поможет. Помогут только оргтехмероприятия. Вот в приличных-то домах Мария Степановна логинится в какую-нибудь службу каталогок, все документы передаёт через клиента СУБД, а порты USB у неё и вовсе наглухо запаяны по соображениям инфобезопасности. Вот в таких условиях отказоустойчивость есть.

>>2738236
> в отличии от
Как написано выше, отличие есть, а смысла в нём на грош.
Аноним (Microsoft Windows 10: Firefox based) 20/02/20 Чтв 11:39:36 273824741
>>2738246
>Как написано выше, отличие есть, а смысла в нём на грош.
Спору нет. Я в юности работал в конторе, где владелец компании менял себе джипы, при этом жлобился на пеку для хранения бэкапов, копируя всё на говняный внешний винт, пока всё в один прекрасный день не пизданулось вместе с компьютером бухгалтера. Отказоустойчивость уровня нищекомпа у главбуха играющего роль "сервера" и внешнего винта ноунейм китайцев.
Аноним (Linux: Firefox based) 20/02/20 Чтв 11:44:57 273824942
>>2738246
>Так тут RAR-то не поможет.
Если бы zip умел в частично восстановление, как rar. То хотя бы часть убитой таблицы можно было спарсить вручную.
>Помогут только оргтехмероприятия.
Снова попытка решить проблему задним числом. Флешку уже принесли, вот она в твоих руках. Ты за неё не несёшь ответственности и никогда не нёс. Ты видишь Марии Степановну первый раз в жизни. Тебя просто просят помочь, а ты вместо этого с чувством собственной значимости начинаешь тыкать пальцем в джип начальника.
Аноним (Microsoft Windows 10: Firefox based) 20/02/20 Чтв 11:56:54 273825543
>>2738236
>функция есть, просто её нет, неиспользована
Оправдания уровня двача. Какая разница что там в винраре, если в архиве, который тебе нужно восстановить, её нет и ты соснул. И это никак не исправить, никто этой херней не пользуется, только потеря места.
Аноним (Linux: Firefox based) 20/02/20 Чтв 13:29:52 273828544
>>2738247>>2738249
> владелец компании менял себе джипы
Смысл существования конторы был в этом. А ты ещё и хотел, чтобы эффективный собственник от себя оторвал кусок на инфраструктуру? Это для эффективных собственников и менеджеров, как показывает мировая практика, есть генеральная линия — снижение затрат, повышение прибылей любой ценой, пусть, даже это будет виселица. Тут бы Даннинга вспомнить, но я приведу другой пример.
Во второй половине XVII века свой пик проходила Голландская Ост-Индская компания. Даже по сегодняшним меркам, это была, скорее всего, самая богатая и могущественная транснациональная корпорация. В то же время Ост-Индская компания была и у англичан, но у англичан была компания на стадии роста. XVII век для обоих хозяйствующих субъектов отмечен был многочисленными вооружёнными противостояниями в ЮВА. У хозяйствующих субъектов сих схема была для капитала стандартная — приватизация прибыли, социализация убытков. В связи с чем, сражались за интересы каждой ТНК, как не трудно догадаться, солдаты государств-носителей. Тем не менее, разница была. Голландцы были богаче, имели свою ЧВК (превосходящую по численности английский экспедиционный корпус и имеющую серьёзно более выгодное логистическое плечо), но направили её на расширение грабежа колоний; соответственно, ресурсы для поддержания были направлены не на противостояние, а на грабителей. Англичане же сделали ставку на «частно-государственное партнёрство». Так началась банкротство Голландской Ост-Индской компании и история «Великой Британской Империи, над которой не заходит солнце».
Голландцам следовало своих воинов-бюджетников поддержать, но они с охотой пошли на риск. Конец был немного предсказуем, но никого в очаге разврата центре принятия решений это не смущало.
Такие дела.


> Если бы zip умел в частично восстановление, как rar.
> То хотя бы часть убитой таблицы можно было спарсить вручную.
Может быть. Но я против такой «работы». Т. к. это расход времени с чудовищной неэффективностью. Да и доверять долбоёбам важные документы — так себе затея.

> Снова попытка решить проблему задним числом.
Отнюдь! Это именно что проактивная позиция — резать к чёртовой матери, не дожидаясь перитонита сразу сделать как надо.

> Тебя просто просят помочь, а ты вместо этого с чувством собственной значимости начинаешь тыкать пальцем в джип начальника.
Зачем же так сразу-то обижаться и обижать? Здесь есть ещё одно мероприятие — техучёба. Объясняешь, почему произошло именно так, что помочь нельзя никак, что документы придётся изготовить вновь и по-быстрее, что впредь к столь важным документам нужно относиться бережно. Это нормально — учиться на ошибках. Тем более, что на моей памяти были десятки случаев, когда из-за переполнения в программе контроллера флешки просто умирали, с десяток случаев, когда NAND-микросхема от перегрева умиирала совсем. И только один случай с бэд-блоком. Извини, но в защиту RAR я даже с натяжкой твой пример отнести не могу.
Аноним (Linux: Firefox based) 20/02/20 Чтв 13:37:08 273828645
Аноним (Linux: Firefox based) 20/02/20 Чтв 16:04:53 273834246
83472610b914da1[...].jpg (31Кб, 500x260)
500x260
>>2738249
>Если бы
Да кобы во рту вырослиб грибы
Это был бы тогда не рот а о-го-ро-д

> То хотя бы часть убитой таблицы можно было спарсить вручную.
Да ненужно это никому.
Ненужно бухгалтерше, ненужно владельцу, ненужно тебе.
И тем боле ненужно разработчикам.

>Флешку уже принесли, вот она в твоих руках.
>Ты за неё не несёшь ответственности
>и никогда не нёс.
>видишь Марии Степановну первый раз в жизни
>начинаешь тыкать пальцем в джип начальника
По моему справедливо, лол.
Если Мария не крокодил, и она хотя бы готова тебя отблагодарить как полагается, то может и стоит поднапрячься, сделать вид бурной деятельности.

А то я тебя не понимаю, тип ради того чтобы ты раз в столетие стал сельским джон сновом мировой ати индустрии нужно жопу рвать?
Аноним (Microsoft Windows 7: Firefox based) 21/02/20 Птн 10:14:10 273863547
>>2738166
>В геометрию «царского пути» нет. Но кое-что пояснить можно на пальцах.
Дело не в этом. О тех же вещах можно рассказать гораздо проще, и это хорошо видно.

>Чтобы вы тоже могли такими стать.
Я здесь, чтобы деградировать. То есть, если бы я просил литературу это одно, но ни я, ни кто-то еще ее не просил, а задавали конкретные вопросы, адресованные гипотетическим людям, которые разбираются. Опять же, если не хочешь тратить время, чтобы объяснять на пальцах, можно пройти мимо, как делают большинство. А вот когда просят литературу по теме, это уже другое дело.

Объяснил опять хуево, с кучей абсолютно не нужной мне информацией, вместо того, чтобы объяснить во что конкретно такое обстоятельство дел будет выливаться для меня на практике.
В моем мире только гигабайты/террабайты, длительность хранения информации, длительность использования носителя, среднее прошедшее время до возникновения первых проблем, в зависимости от размера информации, и вероятность эти проблемы решить в зависимости от разных методов отказоустойчивости, с числами в отрицательной степени я так же работать не привык. Копипастить по памяти научную инфу из пейпера, это конечно очень здорово да, но мне это ничего не говорит.
Собственно, это я и имел ввиду. Но ты видимо этого не умеешь или не хочешь.
Что ж, спасибо за потраченное время, так или иначе. Но ничего нового я не узнал, а мнение осталось такое же:
1.Надежнее и удобнее просто все бекапить.
2.От добавления информации для восстановления в архивах винрара, может быть определенная польза.

Ссылки конечно сохраню на всякий случай. Но вряд ли буду читать.

Тот кун правильно привел ситуацию с дискетой. Ему опять в ответ начали какой-то идеалистической ситуацией срать, в пример приводить, какие-то там бизнесы и т.д., это все вообще не важно. У тебя есть важная информация, ты ее архивируешь на дискету тете сраке и отдаешь на безграничное по времени хранение в непонятно каких условиях, все. А то что типа, моя хата с краю, мне там похуй, что с файлом будет, ведь это уже не ко мне отношение имеет - ну про таких эгоистичных гондонов это уже отдельный разговор.
Что касается копирования файла вместо архивации - можно просто "запаковать" без сжатия и сделать информацию для восстановления 100%, в этом случае возможно шанс восстановления в случае проблем будет даже выше чем если ты просто скопировал, и не надо объяснять сраке, зачем там копия одной и той же папки с 10 файлами, и что копию удалять не надо. А что не надо трогать архив, объяснить легче - ведь это так увлекательно - распаковывать архив!

>> В целом не слишком убедительный пост.
>> Напоминает ситуацию, когда в теории то все заебись, а вот на практике
>Обычно в таких случаях я рекомендую оппоненту на практике испытать прочность законов физики, действующих в наблюдаемой части вселенной. Иначе говоря, предлагаю пойти и удариться головой о бетонный блок. Я привёл ссылки на практические исследования на аппаратной базе. Тру по ссылкам не ходят, но всё же.
Ну вот практика это дискета у бабы сраки, а не законы физики. Или то, что ты всего предусмотреть никак не можешь.
Опять же, понятно, что современные флешки это не дискеты, но блин, сраной флешке у меня тоже точно доверия нет.
Аноним (Microsoft Windows 10: Firefox based) 22/02/20 Суб 14:06:56 273919048
Надо было R-Studio или GetDataBack юзать.
Аноним (Microsoft Windows 8: Chromium based) 23/02/20 Вск 00:16:00 273949949
>>2738249
>Снова попытка решить проблему задним числом.
Ну так ты такой интересный. Бэкапы Марьстепанна делать не могёт, копии не могёт, на почте нигде не осталось, а вот в рар она обязательно будет запаковывать, да с 2% дерьма информации для восстановления непременно. Сферическая ситуация в вакууме.
Аноним (Linux: Firefox based) 23/02/20 Вск 00:21:38 273950350
>>2739499
Не приставай к верующему человеку! Ему же авторитетный дядя сказал, что ему отказоустойчивую функцию добавили. Он не хочет принимать рациональных аргументов. Он верит.
Аноним (Microsoft Windows 10: Chromium based) 23/02/20 Вск 00:31:23 273951151
>>2725889 (OP)
Хуй знает, рекува грят гавно. Восстанавливал однажды затертую флешку через DMDE - всте восстановил без проблем, тысячи файлов.
Аноним (Microsoft Windows 10: Firefox based) 27/02/20 Чтв 01:38:16 274162652
>>2728333
Шта? Я еще в 2007 бугуртил, что в 7з нет такой инфы для восстановления.
Аноним (Microsoft Windows 10: Firefox based) 27/02/20 Чтв 01:42:12 274162853
>>2731719
> из всех когда-либо созданных мной архивов, повреждался только один и когда-то очень давно
А у меня на первой пеке взбунтовалась материнка и стала бить файлы. Любое копирование крупных файлов происходило с ошибками. До сих пор не ебу что это было, оператива и проц точно были исправны. Вся скачанная музыка во флаке стала под угрозой, и только раровская инфа для восстановления спасала. Каждый альбом закаковывал в рар, и хоть архив потом распаковывался с ошибками, но 10% рекавер-инфы помогало восстановить оригинальный файл.
Аноним (Microsoft Windows 10: Firefox based) 27/02/20 Чтв 01:42:59 274162954
>>2741628
> закаковывал
забавно очепятался
Аноним (Linux: Firefox based) 27/02/20 Чтв 09:43:59 274170855
>>2741628
> на первой пеке взбунтовалась материнка и стала бить файлы
> копирование крупных файлов происходило с ошибками
> Каждый альбом закаковывал в рар
> 10% рекавер-инфы помогало восстановить оригинальный файл
Отказоустойчивый стек уровня /b/. Именно тот онанизм, о котором я говорил в >>2737846>>2738166. Прямо классика рационализации постфактум: то надуманный юзкейс с Марьстепанной (которой информация для восстановления RAR-архивов поможет восстановить файлы даже с потерянной флешки), то охуительная история про системную плату, которую нужно было сразу менять.

>>2741626
Там с самого 2003 г. в багтрекере бугуртят.
Аноним (Microsoft Windows 10: Firefox based) 28/02/20 Птн 04:19:51 274224956
А есть и наоборот - вроде до недавнего времени винрар не умел сохранять одинаковые файлы как ссылки, что в 7з было с хуйзнаеткогда времен.
Аноним (Microsoft Windows 10: Firefox based) 28/02/20 Птн 04:21:45 274225057
>>2741708
> нужно было сразу менять
Не сразу, а через года два после покупки, до того все было идеально. Да и сам компец был уровня сборочки из эльдорадо и проц пень д, там только все заменить лол.
28/02/20 Птн 07:15:04 274227558
anacef.jpg (19Кб, 326x322)
326x322
>>2741628
>Любое копирование крупных файлов
ты где "крупные файлы" хранил? на материнке? нахуя и куда ты их копировал? и главное - ЗАЧЕМ?
Аноним (Microsoft Windows 10: Firefox based) 28/02/20 Птн 10:22:45 274231559
>>2742275
Любой файл типа архива крупнее 100 мегов при переносе с одного раздела харда на другой бился. Даже вот прям тут на месте созданный архив без инфы для восстановления распаковывался с ошибками, например. Проги типа офиса в самораспаковывающихся exe отказывались устанавливаться. А вот с харда на флешку и наоборот ничего не билось. Сам охуевал с этого бреда.
28/02/20 Птн 10:37:49 274232260
mauskak.jpg (291Кб, 600x509)
600x509
Аноним (Microsoft Windows 10: Firefox based) 28/02/20 Птн 10:55:51 274233061
>>2742322
Ну а хуле было делать, если школотрону наконец подарили первую пеку? Пока не появился ноут, приходилось сидеть на этой параше.
28/02/20 Птн 11:20:58 274234062
Настройки X
Ответить в тред X
15000 [S]
Макс объем: 40Mб, макс кол-во файлов: 4
Кликни/брось файл/ctrl-v
Стикеры X
Избранное / Топ тредов