Как проверить, будет ли File.Delete () успешным, не пытаясь это сделать, в C #?
istream_iterator не следует использовать для чтения двоичных файлов. Он использует operator>>, что также не подходит для чтения двоичных файлов (если эти файлы не имеют особого формата, который не подходит большинству двоичных файлов). Вместо этого вы можете использовать istreambuf_iterator . Вы также хотите открыть файл в двоичном режиме.
in.open("filepath", std::ios::in | std::ios::binary);
8 ответов
Взгляните на эту статью - http://www.codeproject.com/KB/files/UserFileAccessRights.aspx
Вы пробовали System.IO.File.GetAccessControl (filename) , он должен вернуть FileSecurity с информацией о разрешениях для этого файла.
Проблема с реализацией FileIsDeletableByCurrentUser заключается в том, что это невозможно сделать. Причина в том, что файловая система - это постоянно меняющийся элемент.
Между любой проверкой файловой системы и следующей операцией может произойти любое количество событий. Включая ...
- Права доступа к файлу могут измениться
- Файл может быть удален
- Файл может быть заблокирован другим пользователем / процессом
- USB-ключ, на котором находится файл, может быть удален
Лучшая функция, которую вы могли бы написать, наиболее подходящим образом назвала бы FileWasDeletableByCurrentUser .
Строго говоря, исключение UnauthorizedAccessException означает, что путь является каталогом, поэтому вы можете использовать команду типа System.IO.Path.GetFileName (путь) и перехватить исключение аргумента.
Но если вам нужно более целостное решение, используйте System.IO.File.GetAccessControl, как упомянул Дейл Холливелл
Как указано выше. Найдите права доступа к файлу и сравните их с пользователем, который запускает приложение.
Вы всегда можете использовать этот подход
bool deletemyfile()
{
try
{
...delete my file
return true;
}
catch
{
return false;
}
}
, если он возвращает false, вы знаете, что он не удался, если он возвращает true, тогда ... он сработал, и файл исчез . Не знаю, что именно вам нужно, но это лучшее, что я мог придумать
Конечно, вы можете проверить флаги ReadOnly, используя System.IO и, возможно, безопасность ACL для файла, объединенного с текущим пользователем, но, как пишет Мердад в своем комментарии, это никогда не будет полностью доказано в все дела. Таким образом, для исключительных случаев вам потребуется обработка исключений в любое время (даже если это просто универсальная функция верхнего уровня , которая регистрирует / показывает «неожиданную проблему» и убивает ваше приложение).
Вы должны получить список управления доступом (ACL) этого файла.
Но это не обязательно означает, что вы действительно можете удалить его, потому что флаг readonly все еще может быть установлен или другая программа заблокировал файл.
Похоже, что было бы проще делать что-то в следующем порядке:
- Получить всю необходимую информацию о файле для выполнения других частей (удаление данных из базы данных и т. Д.)
- Попробуйте удалить файл
- Если вы успешно удалили файл, выполните остальную работу по «очистке». Если вы не удалили его, верните / обработайте исключение и т. Д.