… и концы в воду.
Эта неделя началась замечательно, - а именно с безуспешных попыток выяснить, почему валиться билд. Надо сказать, что и в невоенное-то время разобраться, что именно поломалось бывает непросто. Но в этот раз все было еще веселее чем обычно. Некая утилита (не будем показывать пальцем, хотя утилита написана на .NET 
), выдавала примерно следующий лог:
...
> FooBar: parsing Z:\temp\tmp1234.tmp
> FooBar: error XXXX, line 123, Z:\temp\tmp1234.tmp
...
Небольшая заминка была только в том, что утилита аккуратно удаляла «Z:\temp\tmp1234.tmp» вслед за неудачной попыткой его разбора. Действительно, кому придет в голову посмотреть, что там в линии 123, если этот файл и не парсится-то толком, правда?
Ну, файл мы, конечно, восстановили, с проблемой разобрались, но осадок остался. О чем думал писавший эту утилиту не понятно. К сожалению, это далеко не единственный случай, когда возможность понять что произошло приносится в жертву, эээ…, стремлению прибраться за собой. Хотите примеров? Их есть у меня.
nmake.exe позволяет создавать временные файлы с помощью вот такого синтаксиса:
<<
abc
123
<<[KEEP | NOKEEP]
Во время выполнения, текст между скобками копируется в файл, имя которого подставляется в выполняемую команду. Опции KEEP и NOKEEP указывают время жизни файла. По-умолчанию или если указана опция NOKEEP, файл будет удален по завершению выполнения всех команд. Кроме невозможности посмотреть содержимое этого файла (между скобками можно использовать макросы), это означает, что при случае, разработчик не сможет просто скопировать ошибочную команду из лога, чтобы повторить её. Вместо этого ему придется запускать нужную команду или всю последовательность команд через nmake. Это может показаться не очень большой проблемой, но только до того момента, как вам придется разбираться почему вдруг не собирается компонент написанный не понятно кем, несколько лет назад и ни разу не менявшийся с тех пор.
Похожие проблемы возникают сплошь и рядом там, где создаются разного рода response файлы, позволяющие обойти ограничение на размер командной строки. Почему-то авторы скриптов любят их удалять после завершения компиляции. Зачем? Не понятно.
[...] from blog.not-a-kernel-guy.com. Published Thursday, June 26, 2008 7:47 AM by alexeypa Filed under: Инструменты, [...]
> Зачем? Не понятно.
Не удалять - очень просто. Удалить - просто. Вставить условное удаление - может быть сложно.
Если просто не удалять - то http://users.livejournal.com/_adept_/62484.html
Поэтому не удаляют.
BTW, а настроить права на папку, что бы можно было всё кроме удаления - это возможно?
Ну с этим как раз-то бороться очень просто. Не нужно создавать временные файлы на общей куче в %TEMP%. Их нужно помещать туда же, куда пишутся .obj и прочие промежуточные файлы. А удалять - в начале “чистой” сборки.
По идее можно.
не будем показывать пальцем, хотя утилита написана на .NETПодкралось ощущение, что вы не очень любите .NET :). Ощущение верное?
Не-а.
Я предполагаю, что в такой большой компании как Майкрософт должны быть стандарты логов для утилит типа нмейк и прочих.
Если это не так, то при определенных условиях можно напрячься (что естественно, теоретически, должно случаться не очень часто) и втулить брейкпоинт на DeleteFile или на CloseHandle (в случае если файл был открыт с DELELTE ON LAST CLOSE) и просто подменить хендл который передается в функцию. Операционная Система ругнется и не удалит файл.
Guidelines != Standards. И потом даже при безукоризненом ведении логов остается проблема поиска ошибки. И чем больше операций выполняется, тем сложнее найти источник проблемы.
А можно просто поправить исходники соответствующей утилиты. Или воспользоваться undelete. Или еще что нибудь. Основная проблема совсем не в том, чтобы восстановить или не дать удалить этот файл. Проблема в том, как локализовать место ошибки. Возможность повторно запустить любую команду с любого места и получить такой же результат очень ценна.
Я не коим образом не советую решать эту проблему именно таким путем. Я имею ввиду, что если как-нибудь в пятницу, перед самым релизом что-то сломалось, и нет никого рядом кто бы мог поправить сорцы нмейка, то можно не особо напрягаясь подменить хендл и продолжить резерч дальше.
Относительно проблемы поиска ошибок. У меня тестеры написали утилиту которая парсит логи и выцепляет интересные моменты.
Мы не о том спорим. Диагностика есть, куда уж без неё. Я просто говорю, что ни один инструмент не совершенен. Когда этих инструментов сотни, эти маленькие недочеты начинают проявлять себя во всей красе. “Заметание следов” - один из них.
Скажем в данном конкретном случае идея перехватить DeleteFile под отладчиком была, но отпала так как нужно было запускать под отладчиком целый скрипт (с десятками порожденных процессов) и ловить нужный процесс. А все из-за того, что “сбойная” команда зависела от того, как отработают предыдущие, которые состояли в запуске того же .exe с другими параметрами. Можно такое поймать под отладчиком? Да без проблем. Только undelete в 100 раз проще.