Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Слава, Вы писали:

S>>>UPD. И да, FileOptions.DeleteOnClose подходит не всегда. Чтоб не спорить — у нас точно такой же хелпер есть для директорий. Что с ними делать будем? ; )

С>>Нет абсолютно никакого способа закрыть доступ к некоему каталогу. Поэтому, и гарантировать его удаление нельзя.

S>Кэп
S>Так делать-то что?

Да ничего. Посмотри в свой Temp. У меня там 125 папок и еще порядка 1000 файлов. Ни одна создававшая их прога не сообщала мне "ойойой, не могу стереть папку/файл!!!" , а просто тихо оставляла ее в Temp и все.

Здравствуйте, Sinix, Вы писали:

S>Кэп
S>Так делать-то что?

Я во-первых не очень понимаю, для чего может потребоваться временный каталог. Ну ладно, положим он нужен. При удалении временного каталога может быть две стратегии — удалять всё, что в нем есть и удалять только то, про что мы знаем, что это наше, нами созданное, а знать мы может, если временные файлы будут создаваться тем же объектом, который создал каталог. Можно указывать эти стратегии в конструкторе, и также в конструктор подавать какой-нибудь callback, который будет вызываться при невозможности удаления каталога. Этот callback должен быть необязательным.

Здравствуйте, aloch, Вы писали:

A>Да ничего. Посмотри в свой Temp. У меня там 125 папок и еще порядка 1000 файлов. Ни одна создававшая их прога не сообщала мне "ойойой, не могу стереть папку/файл!!!" , а просто тихо оставляла ее в Temp и все.

Это потому что авторы прог — мудаки. Могли бы при выходе попытаться стереть оные файлы.

Кстати, многие unistaller'ы в давние времена после удаления своей программы писали что-то вроде "Can't remove c:\program files\coolgame\saves"

S>Long story short: у нас в CodeJam среди кучи других полезняшек есть микро-хелпер для работы с временными файлами: завёл-поработал-оноавтоматомгрохнулось.
Игнорировать невозможность удаления нехорошо. Но и прерывать выполнение задачи из-за такой ерунды тоже.
Необходимо запомнить название файла куда угодно(напр. реестр) и при последующем вызове попытаться вновь удалить в фоне.
После нескольких попыток, бросить спец. событие для сообщения пользователю.

Здравствуйте, namespace, Вы писали:

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

Ну как как и подозревал: сколько людей, столько и предпочтений по обработке исключений.

Всем не угодишь, поэтому оставим максимально дубовый вариант: запись ошибок в свой TraceSource, по аналогии с WPF PresentationTraceSources. Если этого не хватает, то будет проще написать свой код, кем прогнуть простенький хелпер под конкретный сценарий.

Здравствуйте, Sinix, Вы писали:

S>Всем не угодишь, поэтому оставим максимально дубовый вариант: запись ошибок в свой TraceSource, по аналогии с WPF PresentationTraceSources. Если этого не хватает, то будет проще написать свой код, кем прогнуть простенький хелпер под конкретный сценарий.

Ну раз у вас библиотека всяких разностей, кто мешает вам накопипастить одну и ту же функцию несколько раз с разными вариантами обработки ошибок?

Здравствуйте, koandrew, Вы писали:

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

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

Т.е. вместо простенькой штуки с абсолютно очевидным сценарием использования получается целый комбайн, который я точно не хочу поддерживать. Если кто из команды возьмётся — честь и похвала, только у нас и движухи-то в команде нет. Потому что всё очевидное-интересное сделано, а реальную работу типа исправления ошибок, добавления тестов где их нет, или документации делать чего-то не тянет (и да, меня тоже ). Так что пока делаем что нужно и не более того.