Случайная ошибка в Linux
Linux удаляет файл полностью по-другому, чем способ, которым делает Windows. Во-первых, краткое объяснение о том, как файлами управляют в *собственные файловые системы Unix.
Файл сохранен на диске в многоуровневой названной структуре i-node. Каждый i-узел имеет уникальное число в единственной файловой системе. Структура i-узла хранит другую информацию о файле, как его размер, блоки данных выделенный для файла и т.д., но ради этого ответа самый важный элемент данных является a link counter. directories файлы, которые ведут учет о файлах. Каждая запись имеет число i-узла, которое она отсылает к, длина имени файла и само имя файла. Эта схема позволяет иметь 'указатели', т.е. 'ссылки' на тот же файл в различных местах с различными именами. Счетчик ссылки i-узла на самом деле сохраняет количество ссылок, которые относятся к этому i-узлу.
Что происходит, когда некоторый процесс открывает файл? Сначала open() функционируйте ищет запись файла. Затем это проверяет, существует ли структура i-узла в оперативной памяти для этого i-узла уже. Это может произойти, если некоторому приложению уже открыли этот файл. Иначе система инициализирует новую структуру i-узла в оперативной памяти. Затем система увеличивает структуру i-узла в оперативной памяти открытый счетчик и возвращает приложению его дескриптор файла.
Вызов библиотеки Linux для удаления файла называют unlink. Эта функция удаляет запись файла из каталога и постепенно уменьшает счетчик ссылки i-узла. Если система нашла, что структура i-узла в оперативной памяти существует, и ее открытый счетчик не является нулем затем, этот вызов возвращает управление приложению. Иначе это проверяет, стал ли счетчик ссылки нулем и если это делает затем систему, освобождает все блоки, выделенные для i-узла и самого i-узла, и возвращается к приложению.
Что происходит, что приложение закрывает файл? Функция close() постепенно уменьшает открытый счетчик и проверяет его значение. Если значение является ненулевым, функция возвращается к приложению. Иначе это проверяет, является ли счетчик ссылки i-узла нулем. Если это - нуль, это освобождает все блоки файла и i-узла прежде, чем возвратиться к приложению.
Этот механизм позволяет Вам "удалять" файл, в то время как он открыт. В то же время приложение, которое открыло файл все еще, имеет доступ к данным в файле. Так, JRE, в Вашем примере, все еще сохраняет свою версию файла открытой, в то время как существуют другой, обновленная версия на диске.
Больше эта функция позволяет Вам обновлять glibc (libc) - оперативную библиотеку всех приложений - в Вашей системе, не прерывая ее нормальное функционирование.
Windows
20 лет назад мы не знали никакую другую файловую систему, чем FAT под DOS. Эта файловая система имеет другую структуру и принципы управления. Эти принципы не позволяют Вам удалять файл, когда он открыт, таким образом, DOS и в последнее время Windows должны отклонить, любой удаляет запросы на файле, который открыт. Вероятно, NTFS позволил бы то же поведение, как *отклоняют файловые системы, но Microsoft решила поддержать обычное поведение удаления файла.
Это - ответ. Не короткий, но теперь у Вас есть идея.
Править: Хорошее чтение на источниках Win32 путаница: https://blogs.msdn.microsoft.com/oldnewthing/20040607-00/? Кредиты p=38993 к @Jon
Генераторы случайных чисел программного обеспечения не являются единственным источником энтропии в системе. На самом деле они не источники энтропии вообще - использование программного обеспечения RNGs внешние энтропийные источники для предоставления энтропии к системе. Реальный источник всегда является физическим (быть этим выделенное оборудование RNG, температурные датчики, аудиовход, синхронизация сетевых пакетов, вводы данных пользователем или даже внутренние состояния ЦП (которые для виртуального ЦП не являются строго "физическими" в некотором смысле) - Вы называете его).
Теперь что касается Вашего вопроса: как Mat упоминает в своем комментарии, большинство ошибок происходит из-за неаккуратного дизайна/кодирования (/тестирующий) - я пошел бы, до для высказывания это - 100%. Мое предположение - то, что Ваш код испытывает некоторое состояние состязания, которое обрабатывается плохо (если вообще). Так в некотором смысле это - связанная энтропия (как состояние состязания является случайным событием). Обвинение RNG для него является довольно полужирным оператором, по крайней мере - если Вы не используете случайные числа для инициирования его, в этом случае это больше походит на функцию.
Между прочим, если бы поврежденный RNG был причиной Ваших проблем, то Вы на самом деле видели бы их скорее очевидно. Относительно ошибки Debian OpenSSL - я не думаю, что любое другое распределение кроме Debian базировалось, (включая Ubuntu) был поражен им. Все же сама ошибка является довольно воспитательной с точки зрения того, как это, возможно, произошло во-первых.
-
1+1 в течение времени и взятого effor. Я знаю, что реальный источник энтропии (или источники, скорее), физический... Я полагаю, что статья даже упомянула random.org, например, и как они могут использоваться с antena's радиоволны и что имеет Вас. Состояние состязания было, действительно наша первая остановка, также..., но - и я сожалею, что не могу подробно остановиться на этом далее, потому что это моча меня не часть используемого программного обеспечения является закрытый исходный код. Насколько мы знаем, ошибка появилась откуда ни возьмись. Мы, в настоящее время, выполняем моделирования, пытаясь воспроизвести то, что на самом деле произошло. Существуют другие исследуемые вещи, также – Elias Van Ootegem 24.09.2013, 14:29
-
2Но я просто не забыл читать о такой ошибке и хотел illiminate это от списка подозреваемых, вместо того, чтобы подтвердить это. Теперь, когда я считал свой вопрос снова, я вижу, как неправильное представление моего обвинения/dev/random или независимо от того, что появилось... – Elias Van Ootegem 24.09.2013, 14:31
-
3я предполагаю единственный совет, помещает большой вход отладки и выполнение с этим. Любой, которого Вы закрепляете ошибку в своем коде (легче зафиксировать) или в том, что не находится под Вашим контролем (отчаянный от POV пользователя, но по крайней мере можно чувствовать себя лучше как программист). – peterph 24.09.2013, 15:34