В моей производственной среде у нас было то, что мы считаем
поврежденный хранимый хеш, созданный Storable.pm. Я не могу повторить поведение в Dev, что затрудняет точную диагностику.
Код работал долгое время, и изменения, которые сделали его
разрыв был удален из хеша. До недавнего времени хэш либо
остался прежнего размера или вырос.
Файл открывается в режиме readwrite, а затем store_fd записывает в файл.
Поскольку хэш теперь (иногда) меньше, он будет писать, скажем, 1000 байт
этот 2000-байтовый файл. Хвостовые 1000 байтов являются старыми, мусорными данными. В моем
тестовые случаи, когда я получаю хэш, данные мусора игнорируются, как
ожидается.
open( $sf, "+< $self->{mod_state_filename}" );
flock( $sf, LOCK_EX );
$self->{mod_state} = fd_retrieve($sf);
delete ($self->{mod_state}{"somekey"});
seek( $sf, 0, 0 );
store_fd( $self->{mod_state}, $sf );
flock( $sf, LOCK_UN )
close($sf);
Мои вопросы:
- Должно ли это работать или это
обязательно ли урезать файл?
- Использует ли хранимый хеш какой-либо вид
символа конца файла? Если так,
что это?
- вышеуказанный код, удаляя
и добавление и удаление и добавление,
отлично работает в моем тестовом случае. Можно
Вы предлагаете любую последовательность тестов
это может привести к сбою, из-за
не усеченный файл? (Я знаю это
это действительно расплывчатый вопрос, поэтому чувствую
свободно игнорировать это).