Что такое код file_exists


File.exists() возвращает false для файла (каталога), который действительно существует

TLDR: File.exists() глючит, и я хотел бы понять почему!

Я столкнулся со странной проблемой (как это часто бывает) в моем приложении для Android. Я постараюсь быть максимально кратким.

Сначала я покажу вам код, а затем предоставлю дополнительную информацию. Это не полный код. Просто суть проблемы.

В большинстве случаев это работает нормально. Однако несколько раз выдается исключение, что означает, что каталог не существует и не может быть создан. Из каждых 100 прогонов он работает нормально 95-96 раз и дает сбой 4-5 раз.

  • Я объявил разрешения для хранения/чтения внешнего хранилища/записи внешнего хранилища в моем манифесте и asked for the permissions on runtime. The problem does not lie there. (If anything i have too many permissions at this point :D). After all, if it was a permission issue it would fail every time but in my case it fails at a rate of 4% or 5%.
  • запросил разрешения во время выполнения. Проблема не в этом. (Во всяком случае, у меня слишком много разрешений на данный момент: D). В конце концов, если бы это была проблема с разрешением, она бы терпела неудачу каждый раз, но в моем случае она терпела неудачу со скоростью 4% или 5%.С помощью приведенного выше кода я пытаюсь создать файл, который указывает на папку «Документы». В моем приложении я на самом деле использую String myPath = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOCUMENTS).getPath();
    В конкретном устройстве, где возникает ошибка, этот путь называется «/storage/emulated/0/Documents» и , поэтому я жестко закодировал его в приведенном мной примере кода.
  • Если я использую на устройстве приложение для просмотра файлов (например, «Astro file manager»), я вижу, что папка существует и имеет некоторое содержимое, а также подтверждаю, что путь действительно равен «/storage/emulated/0/Documents».
  • Это никогда не случалось со мной на месте. Проблема возникает только у пользователей приложения, и я знаю, что проблема существует благодаря Firebase/Crashlytics. У пользователей точно такой же планшет, что и у меня, который я использую для разработки, а именно Lenovo TB-8504X. (Я работаю в компании, и мы предоставляем и программное и аппаратное обеспечение).

Итак, у вас есть какие-либо мысли о том, почему возникает эта проблема?

Кто-нибудь когда-нибудь испытывал нечто подобное?

Может ли путь к папке «Документы» иногда быть «/storage/emulated/0/Documents» и иногда становиться чем-то другим на том же физическом устройстве?

Я опытный разработчик Android, но я довольно новичок в архитектуре Android и файловой системе Android. Может ли быть так, что при запуске (когда устройство включено или после перезагрузки) файловая система еще не «смонтировала» «диск» в тот момент, когда мой код проверяет, существует ли каталог? Здесь я использую термины «монтировать» и «диск» настолько свободно, насколько это возможно. Кроме того, мое приложение на самом деле является приложением для запуска/родительского контроля, поэтому оно запускается первым при запуске устройства. Я почти убежден, что это вообще не имеет смысла, но сейчас я пытаюсь увидеть более полную картину и исследовать решения, которые выходят за рамки типичной разработки для Android.

Я был бы очень признателен за вашу помощь, поскольку этот вопрос начинает действовать мне на нервы.

Ждем любых полезных ответов.

ОБНОВЛЕНИЕ (27/08/2020):

Я столкнулся с этим Java Bug Report, хотя он довольно устарел. В соответствии с этим, при работе с томами, смонтированными в NFS, java.io.File.exists выполняет stat(2) . Если stat дает сбой (что может произойти по нескольким причинам), то File.exists (по ошибке) предполагает, что файл stat’ed не существует. Может ли это быть источником моих неприятностей?

ОБНОВЛЕНИЕ (28/08/2020):

Сегодня я могу добавить награду bounty к этому вопросу, пытаясь привлечь больше внимания. Я бы посоветовал вам внимательно прочитать вопрос, просмотреть комментарии , игнорируя тот, который утверждает, что это связано с поддержкой клиентов из Realm. Код области действительно используется ненадежным методом, но я хочу знать, поэтому метод ненадежен. Вопрос о том, может ли Realm обойти это и использовать какой-то другой код, выходит за рамки вопроса. Я просто хочу знать, можно ли безопасно использовать File.exists() , а если нет, , почему?

Еще раз спасибо всем заранее. Для меня было бы очень важно получить ответ, даже если он слишком технический и предполагает более глубокое понимание файловых систем NFS, Java, Android, Linux или чего-либо еще!

ОБНОВЛЕНИЕ (30/08/2020):

Поскольку некоторые пользователи предлагают заменить File.exists() каким-либо другим методом, я хотел бы заявить, что то, что меня интересует в данный момент, подчеркивает, почему метод терпит неудачу , а не какой можно использовать вместо этого в качестве обходного пути.

Даже если бы я захотел заменить File.exists() чем-то другим, я не смогу сделать это, потому что этот фрагмент кода находится в файле RealmConfiguration.java (только для чтения), который является частью Библиотека областей, которую я использую в своем приложении.

Чтобы сделать вещи еще яснее, я приведу два куска кода. Код, который я использую в своей деятельности, и метод, который вызывается в RealmConfiguration.java как следствие:

Код, который я использую в своей деятельности:

В этот момент myFile существует, и вызывается код, который находится в RealmConfiguration.java .

Сбой метода RealmConfiguration.java :

Итак, myFile существует в моей деятельности, вызывается код Realm, и внезапно myFile перестает существовать. Снова хочу отметить, что это не соответствует. Я замечаю сбои со скоростью 4-5%, что означает, что myFile большую часть времени существует как в действии, так и когда код области проверяет его.

В чем разница между File.Exists («») и FileInfo

У меня есть файл * .exe в \ ProgramFiles (x86) \ MyAppFolder.

В приложении x86 я проверяю, существует ли файл (64-битная система). простой:

Результат: «fileExists == false» (файл действительно есть). Как я понимаю, это виртуализация. Эта проблема описана здесь. Все хорошо. Но следующий код:

Почему результат отличается в первом и втором случаях?

5 ответов

Разницы нет, эти методы используют точно такой же внутренний вспомогательный метод внутри .NET Framework. Что-то, что вы можете увидеть с помощью декомпилятора или исходного кода Reference, вспомогательный метод называется File.FillAttributeInfo ().

Подобное дублирование в .NET Framework довольно необычно, и это не совсем хорошо, когда есть несколько способов выполнить одно и то же. Класс File, однако, особенный, он был добавлен после исследования юзабилити, проведенного до выпуска .NET 1.0. У испытуемых были только базовые классы BCL для работы, такие как FileStream и FileInfo, а в остальном была доступна только документация MSDN. Результаты теста были не очень хорошими, класс File был добавлен, чтобы помочь программистам попасть в пропасть успеха при написании очень простого кода для манипулирования файлами. Как File.Exists () и File.ReadAllLines ().

Так что это не имеет ничего общего с классами, вы просто неправильно их используете. Как на самом деле не использовать тот же путь. Обращайтесь с прямыми слешами проще, сопоставление с обратными слешами происходит внутри Windows и непоследовательно реализуется в другом коде. Использование //определенно не дает того, на что вы надеетесь.

Это единственное отличие, и оно больше связано с природой FileInfo :

Итак, как вы можете видеть, значение fileInfo.Exists кэшируется при первом его использовании.

Кроме того, они делают то же самое за кулисами.

в первом случае путь к файлу неверен, в «Program Files (x86)» нужны пробелы.

Во-вторых, Path.Combine вернет путь к каталогу, поэтому вы получите что-то вроде «C:\Program Files (x86)\MyAppFolder\Manager.exe\» так что это плохая идея.

Оба метода работают одинаково, поэтому убедитесь, что путь указан правильно.

Разница между File.Exists() и new FileInfo().Exists о его поведении, когда полный путь (имя каталога + имя файла) длинный:

Я повторил ваш сценарий, используя приведенный ниже скрипт Linqpad

Запускал это как при наличии файла, так и когда его не было, и оба выдали одинаковый результат каждый раз. Возможно, попробуйте это в вашей системе и посмотрите, видите ли вы различия.

file_exists не чувствителен к регистру

столкнулся с проблемой, что винда не чувствительна к регистру имен файлов и директорий
в результате и функция file_exists не чувствительна к регистру

я проверяю с помощью этой функции установлен ли у меня компонент
имя файла компонента имеет вид class.ComponentName.php
в файле класс с именем ComponentName

тут по большей части проблем нет так как php тоже не чувствителен к регистру имен классов и функций

но боюсь, что где-нибудь из-за этого может возникнуть баг

единственное что мне приходит в голову как решение этой проблемы
так это просканить директорию и получить список всех установленных компонентов,
и ориентируясь на этот список уже подгружать компоненты
но это получается жуткая заморочка и мне так делать не хочется

10 ответов

хороший ответ :D

но вопрос в том
как мне сделать, так что бы загрузчик компонентов был чувствителен к регистру?
если не делать, так как я предложил то как

собственно вспомнил пример бага который может возникнуть

// неверное название
$ComponentName = «TeSt»

// .
// загруска компонента упешно отработает
$classname = «class.» . $ComponentName . «.php» ;
if ( file_exists ( ROOT . $path . $classname ) ) <
include_once ( ROOT . $path . $classname ) ;
$SuperClass -> $component = $ComponentName ;
>

// .
// тут будет ошибка Notice объект не найден и метод вызван не будет
// так как методы классов в пыхе чувствительны к регистру
$SuperClass -> test -> run ( ) ;

собственно я впервые столкнулся с этой проблемой
так как всегда передавал правильные имена компонентов
или на стадии его использования имел доступ к имени, под которым он был загружен
в одном из загрузчиков я добавил к параметрам переменную $usename имя, под которым этот компонент будет использоваться

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

приведение, вызываемое имя к нижнему регистру влечет за собой определенные неудобства, так как имя компонента может состоять из одного и более слов то обращаться к компоненту по имени sumelementtorunerconsole не слишком удобно

в принципе проблему можно решить за счет $usename, но эта переменная тоже формируется на верхнем уровне

PS может, я и зря так дергаюсь, но просто как-то дернуло обнаружение этого бага в моей системе

file_exists Функция проверяет существование файла

Достаточно часто конфигурацию плагина выносят в отдельный файл или требуется сохранить какие то данные в файле на время перезагрузки сервера.
Что бы работать с файлами существуют специальные функции из инклюда file.inc. Начать изучение функций для работы с файлами предлагаю с проверку на существование файла с помощью функции file_exists

Инфо из file.inc:

  • const file[] — Имя файла в кавычках или массив с именем.По умолчанию директория для файла cstrike.

Функция вернет 1, если файл существует, 0 если нет.

Описание:
Пример просто до безобразия.
Для наглядности объявляется новый массив и в него записывается имя файла listip.cfg, который лежит в корневой директории ( для функции).
Далее объявляется новая переменная bFileexist в которую получается результат работы функции, которая проверяет наличие файла на сервере.

И по результатам выводится сообщение в консоль сервера.
Поменяйте название файла на не существующий и результат будет отрицательным.

Как подсказал HoLLyWooD, с помощью данной функции можно проверять наличие файлов перед прекешем или установкой на модель
что-бы избежать падения.

file-exists

с этим кодом, если файл существует, он даст мне ошибку ErrorException в файловой системе.php line 338: mkdir (): файл существует…

Как проверить, существует ли файл в данном пути или нет в Qt? Мой текущий код ниже: QFile Fout(«/Users/Hans/Desktop/result.txt»); if(!Fout.exists()) <…

Я создаю проект установки Windows для приложения Windows Forms. Как правило, наше приложение развертывается на двух разных клиентах, с определенным…

Я сделал сценарий, который берет dir, и scnas через этот dir для файлов изображений, а затем echo’s out these images…

Вот код, который у меня есть для этого, но он никогда не возвращает true. $image = $_FILES[‘image’]; $filename = $image[‘name’];…

По какой-то причине этот PHP код ниже не будет работать, я не могу понять это. Это очень странно, file_exists, кажется,…

Я получил ниже код от tidy-designs, и он работает хорошо, за исключением того, что он не проверяет существующее изображение. когда…

file_exists не работает!! Но когда url ($img в коде) дается в браузере, изображение отображается. Я знаюfile_exists(), что берет только жесткий…

Когда я делаю File file = new File(etc..) я действительно создал этот файл на SD-карте? Iam немного смущен, потому что…

Учитывая путь, по которому вы ищете, и имя файла содержит регулярное выражение, Есть ли способ проверить, существует ли какой-либо файл,…

Привет, я пытаюсь создать файл, если файл еще не существует. Затем я хочу записать 11 нулей в 11 строк, если…

Ниже приведен мой фрагмент кода:

Я знаю язык C поверхностно. На самом деле, мне нужно написать приложение, используя s socketsets client-server, который проверяет существование файла….

Я пытаюсь кодировать эту идею: у вас есть кнопка загрузки. Когда вы нажимаете кнопку, это должно доказать, если файл существует….

Я создал простой PHP скрипт, который читает .txt файлы (1.txt, 2.txt и т. д., Каждый из которых содержит фиктивный текст:…

Я создал функцию для вызова файла из папки. Но проблема в том, что это не соответствующий случай. Моя функция function…

if (file_exists ($_SERVER [‘DOCUMENT_ROOT’]. «/индекс.html»)) echo ‘файл существует’; Возвращает значение «file exists» только в том случае, если для владельца и…

Я вытаскиваю XML-файл и выполняю различные массажи данных. Я назначил элементу (который не имеет данных) переменную и проверил, является ли…

Я отредактировал весь вопрос, чтобы лучше представить ответ. У меня был цикл for, который будет получать доступ и редактировать файлы…

У меня есть сценарий, чтобы скопировать все вложения электронной почты в выбранном наборе писем в папку после некоторого переименования. Поскольку…

Я читал все другие вопросы, касающиеся этого, но мой случай отличается. У меня есть локальная файловая система NAS, которая подключена…

Мне удалось найти способ скачать .txt файлы с веб-сайта, который у меня есть доступ к которому это здорово, но я…

Ранее я задавал некоторые вопросы о том, какой метод я должен использовать, чтобы сохранить некоторые данные из моего приложения, чтобы…

Я настроил загрузку файла, но в некоторых случаях файлы не могут быть загружены. Поскольку file_exist не является истинным, php-код умирает…

Я использую движок шаблонов php Smarty , и я пытаюсь проверить существование .jpg изображения с $ >

Я уже читал темы с похожими вопросами, но не нашел достаточного ответа. У меня есть следующий вопрос: Я разрабатываю большую…

У меня есть массив в контроллере CI, как показано ниже Array ( [user_id] => 109676506743696803215 [sub_dirs] => Array ( [0]…

Некоторые пальцы создаются на сервере с помощью shell_exec («/usr/bin / convert-thumbnail..), файлы создаются правильно на сервере, но file_exists возвращает false…

В настоящее время я разрабатываю веб-сайт Гильдии World of Warcraft для друга, используя wowarmoryapi. однако в настоящее время я делаю…

Я попытался найти, существует ли url-адрес со следующим кодом. Требование состоит в том, чтобы найти, существует ли файл или нет…

Я хотел бы проверить, существует ли данный каталог. Я знаю, как это сделать на Windows: BOOL DirectoryExists(LPCTSTR szPath) < DWORD…

$rest = substr(date(«m/d/Y», strtotime($row[‘autodate’])), 6, 4); $filename = «G://Corporate Operations/Transportation Maintenance/Road Service/ <$rest>road service invoice scans/<$row[‘invoice’]>.pdf»; if (file_exists($filename))

I have a FileExists check in a window open event on A Profile.ini-файл в PB 12.5. (windows 7) и затем…

Привет я запускаю несколько серверов в локальной сети. На одном из этих серверов размещается мой веб-сервер IIS. Я пытаюсь обработать…

Я хочу проверить, содержит ли каталог конкретный файл(любой тип, изображение, pdf и т.д.) или нет. Если он содержит файл, я…

file_exists () возвращает false, но файл существует

У меня очень странная проблема с file_exists (). Я использую эту функцию, чтобы проверить, существуют ли 2 разных файла в одних и тех же папках. Я дважды проверял, они оба существуют.

Теперь давайте используем file_exists ():

Я не понимаю – оба эти файла существуют. Я запускаю Windows, поэтому он не связан с вопросом, чувствительным к регистру. Безопасный режим выключен.

Однако стоит упомянуть, что .png один загружается пользователем через FTP, а .jpg один создается с помощью скрипта. Но, насколько я знаю, это не должно иметь значения.

Результаты file_exists() кэшируются, поэтому попробуйте использовать clearstatcache() . Если это не помогло, перепроверьте имена – они могут быть похожими, но не одинаковыми.

Это из-за безопасного режима. Вы можете отключить его или включить каталог в safe_mode_include_dir. Или измените права на файлы / разрешения для этих файлов.

php.net: file_exists ()
php.net: безопасный режим

Я обнаружил, что то, что работает для меня, чтобы проверить, существует ли файл (относительно текущего файла php, который он выполняется), является частью кода:

Просто мои $ .02: у меня была эта проблема, и это было из-за пробела в конце имени файла. Это не всегда проблема пути, хотя это первое, что я проверяю – всегда. Я мог бы вырезать и вставить имя файла в окно оболочки с помощью команды ls -l и, конечно же, найти файл, потому что в командной строке будет игнорироваться пространство, в котором нет файлов file_exists. Очень расстраивать действительно и почти невозможно найти, если бы не StackOverflow.

СОВЕТ. При выводе операторов отладки заключают значения с разделителями () или [], и это будет довольно ясно отображать пробел. И всегда помните, чтобы обрезать ваш вход.

file_exists() просто не работает с HTTP-адресами.

Он поддерживает только пути файловой системы (и FTP, если вы используете PHP5.)

пожалуйста, обратите внимание:

Попробуйте использовать DIRECTORY_SEPARATOR вместо ‘/’ в качестве разделителя. Windows использует другой разделитель для путей файловой системы (обратная косая черта), чем системы Linux и Unix.

Это также может быть проблемой разрешения на одну из родительских папок или самого файла.

Попробуйте открыть сеанс как пользователь, который запускает ваш веб-сервер и cd. Папка должна быть доступна этому пользователю, и файл должен быть доступен для чтения.

Если нет, php вернет, что файл не существует.

Здесь очень простой трюк, который работал на меня.

Когда я пишу следующую строку, она возвращает false.

И когда я пишу с удалением URL-адреса, начинающегося слэш, он возвращает true.

вы попробовали ручную запись. также ваши два расширения, похоже, в другом случае

Функция custom_file_exists (), вдохновленная ответами @Timur, @Brian, @Doug и @Shahar:

Этот ответ может быть немного взломан, но он работает для меня –

По-видимому, $_SERVER[‘REQUEST_SCHEME’] немного рискован для использования с IIS 7.0 + PHP 5.3, поэтому вы, вероятно, можете найти лучший способ добавить в протокол.

Последние два часа я размышлял о том, что случилось с моим if: file_exists ($ file) возвращал false, однако я мог бы назвать include ($ file) без проблем.

Оказывается, я не понимал, что значение php include_path, которое я установил в файле .htaccess, не переносилось на file_exists, is_file и т. Д.

Просто идет, чтобы показать, что «ярлыки для простоты», такие как установка include_path в .htaccess, могут в конечном итоге вызвать больше горя.

Что такое код file_exists

файл копируется в заранее определенную директорию, на которую у текущего пользователя полные права доступа;
эта копия открывается через Process.Start (т.е. открывается стандратной для этого расширения программой);
копия возможно редактируется и сохраняется под новым именем, содержащим временной штемпель (т.е. в случае редактирования имеем совершенно самостоятельную копию);

** когда надо удалить, после копирования куда надо (копируется только исправленная версия), исходный файл, случается описанный в заголовке феномен (не часто, но все же; и в основном на Вин7).

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

1. antonn , 09.01.2013 13:13
olivenoel
не часто, но все же; и в основном на Вин7
возможно как-то задействован UAC и его виртуализация?
2. Sioln , 09.01.2013 13:50
olivenoel
А вы это не через FileSystemWatcher определяете? Вроде как это его known bug (на самом деле баг ОС).
3. ash of mind , 09.01.2013 14:02
olivenoel
А что имеет место быть на самом деле? (т.е. на самом деле файл есть, или его нет?)

но не слишком ли это накладно для случая удаления файла?
Если через WinAPI’шный CreateFile, то не слишком, т.к. такая попытка есть попытка получения только SafeFileHandle, запрошенного с определенными параметрами. Я так делаю проверку на sharing violation.

цитата: Sioln:
olivenoel
А вы это не через FileSystemWatcher определяете? Вроде как это его known bug (на самом деле баг ОС).

нет. Файлы для удаления ищу через DirectoryInfo.GetFiles(«*.*»). Т.е. они как бы должны существовать, раз GetFiles их находит. Или?

4. olivenoel , 09.01.2013 14:55
5. antonn , 09.01.2013 16:01
похожее поведение? (http://blogs.technet.com/b/mark_russinovich/archive/2009/02/03/3204885.aspx)
одна функция может получить «завиртуаленое» представление каталога, а deletefile() принимает путь к файлу, который физически находится в другом месте (в папке виртуализации в профиле)

цитата: antonn:
похожее поведение? (http://blogs.technet.com/b/mark_russinovich/archive/2009/02/03/3204885.aspx)
одна функция может получить «завиртуаленое» представление каталога, а deletefile() принимает путь к файлу, который физически находится в другом месте (в папке виртуализации в профиле)

вряд ли. Собственно копирование и открытие файлов из «полностью доступной» папки должно было оградить от «занятости» старых файлов разными процессами. Т.е. они должны присутствовать и быть полностью доступными.

6. olivenoel , 09.01.2013 17:11

цитата (olivenoel): File.Exists говорит «да», но File.Delete говорит «файл не найден»

А кто сказал что это файл ? Это может быть и директория. Либо нет соотвествующих прав.

7. vertur , 09.01.2013 23:38
8. olivenoel , 10.01.2013 00:17
я сказала, что это файл. Потому что:

PS: если будет не хватать прав (хотя папка для чистки имеет полные права для AnyUser), то File.Exists вернет ложь. Если путь не существует File.Exists тоже вернет ложь. Потому что

цитата: Параметры
path
Тип: System.String
Проверяемый файл.
Возвращаемое значение
Тип: System.Boolean
true, если вызывающий оператор имеет требуемое разрешение и path содержит имя существующего файла; в противном случае — false. Этот метод также возвращает false, если path — null, недействительный путь или строка нулевой длины. Если у вызывающего оператора нет достаточных полномочий на чтение заданного файла, исключения не создаются, а данный метод возвращает false вне зависимости от существования path.
Заметки
Метод Exists не следует использовать для проверки пути, с помощью этого метода просто проверяется, существует ли файл, заданный в path. Передача недействительного пути в Existsl возвращает false. (c)

Поэтому если мы уже дошли до File.Delete то файл по идее есть и прав на него хватает. И если верить мсдн, то File.Delete не может возвращать «файл не найден», но однако ж.

9. Konstantin Mironovich , 10.01.2013 03:13
1. что значит «файл копируется»? это системная функция? нечто свое?
2. что значит «копия редактируется»? подробно все действия. open(for read), read(to buffer), close, flush ?

что есть в компе, висящего на файловой подсистеме? (бекапы, шифраторы, антивирусы, etc)

10. dozen , 10.01.2013 05:19
olivenoel
И если верить мсдн, то File.Delete не может возвращать «файл не найден», но однако ж.

Приведи-ка ты пример неудаляемого файла (полный путь с именем)? А то я имел как-то альтернативную благодать со странными именами файлов.

Code path для проверки существования и удаления — разный, и что видит один, вполне может не видеть другой (для особых случаев).

11. ash of mind , 10.01.2013 06:21
olivenoel
Потому что:
Если действительно проблемно определиться, существует на самом деле удаляемый файл, или нет, я бы не советовал использовать DirectoryInfo.GetFiles — вместо этого использовал бы DirectoryInfo.EnumerateFiles (http://msdn.microsoft.com/en-us/library/dd383574.aspx) , и далее шел бы по коллекции итератором (foreach). Разница — в том, что второй метод, в отличие от первого, использует lazy evaluation; тем самым во втором случае исключается гипотетическая ситуация пропадания файла во время получения полного массива, и его перебора в цикле.

цитата: Konstantin Mironovich:
1. что значит «файл копируется»? это системная функция? нечто свое?
2. что значит «копия редактируется»? подробно все действия. open(for read), read(to buffer), close, flush ?

что есть в компе, висящего на файловой подсистеме? (бекапы, шифраторы, антивирусы, etc)

Добавление от 10.01.2013 13:05:

цитата: dozen:
olivenoel
И если верить мсдн, то File.Delete не может возвращать «файл не найден», но однако ж.

Приведи-ка ты пример неудаляемого файла (полный путь с именем)? А то я имел как-то альтернативную благодать со странными именами файлов.

c:\Work\ELS15\ELS15 10001256 2012-11-23 153648.xls
c:\Work\ELS15\ELS25 10001286 2012-07-12 111738.xls

Добавление от 10.01.2013 13:08:

цитата: ash of mind:
olivenoel
Потому что:
Если действительно проблемно определиться, существует на самом деле удаляемый файл, или нет, я бы не советовал использовать DirectoryInfo.GetFiles — вместо этого использовал бы DirectoryInfo.EnumerateFiles (http://msdn.microsoft.com/en-us/library/dd383574.aspx) , и далее шел бы по коллекции итератором (foreach). Разница — в том, что второй метод, в отличие от первого, использует lazy evaluation; тем самым во втором случае исключается гипотетическая ситуация пропадания файла во время получения полного массива, и его перебора в цикле.

попробую. Но с исходным файлом ничего не происходит (разве что Thumbs.db). Почему он должен куда-то деваться?

12. olivenoel , 10.01.2013 13:03
13. antonn , 10.01.2013 13:25
а поиском не искали свой файл на компьютере?
14. Konstantin Mironovich , 10.01.2013 18:34
в recycle.bin
15. bislomet , 10.01.2013 19:19
Скажите, а именно в момент возникновения сообщения от Delete — файл существует или нет?
16. Imlb , 10.01.2013 22:18
Кто конкретно врет-то? File.Exists или File.Delete?
Что в исходниках этих функций?

17. as111 , 10.01.2013 23:26
olivenoel

Обратите внимание:
http://msdn.microsoft.com/ru-ru/library/system.io.file.delete.aspx
Посмотрите список исключений, метод File.Delete не выдает исключений типа FileNotFoundException.
Наиболее близкое:
«DirectoryNotFoundException Указанный путь недопустим (например, он соответствует неподключенному диску).»

Есть еще:
«IOException
Заданный файл используется.
-или-
Для файла имеется открытый дескриптор, используется операционная система Windows XP или более ранняя версия.Открытый дескриптор мог появиться в результате перечисления каталогов и файлов.Дополнительные сведения см. в разделе Практическое руководство. Перечисление каталогов и файлов.»

Или
«UnauthorizedAccessException
У вызывающего объекта отсутствует необходимое разрешение.
-или-
path является каталогом.
-или-
Параметр path определяет файл, разрешенный только для чтения.»

У вас какое и исключение выдается при вызове File.Delete? Не текст, а типа исключения?

Обратите внимание еще вот на это:
«Безопасность платформы .NET Framework
FileIOPermission
на удаление заданного файла.Связанное перечисление: FileIOPermissionAccess.Write»

Смысл в том, что метод File.Delete проверяет наличие файла как-то иначе, чем File.Exists.

Посмотрите с помощью, например, JetBrains dotPeek исходники этих двух функций (я посмотрел).

И паттерн
«if File.Exists then File.Delete» в корне неверен.

Тем более, что при вызове File.Delete вам все равно нужно обязательно отлавливать исключения, т.к. это в любом случае операция ввода-вывода в общем случае с непредсказуемыми последствиями,
то заодно и отлавливайте исключение, когда файл не найден.

18. Konstantin Mironovich , 11.01.2013 01:02
as111
Обратите внимание:
сами обратите. у нее дельфи.
19. as111 , 11.01.2013 01:24
Konstantin Mironovich

Где автор писала про Delphi? Уже глубоко в теме, когда привела свои примеры кода?

И что из этого следует.

У автора все функции дотнетовские (File.Delete, File.Exists, DirectoryInfo.GetFiles, Process.Start, т.д.).
Далее, она явно не удивилась вопросу про FileSystemWatcher.
Ну и т.д.

Автор явно пишет на Delphi .NET, и обращается к библиотеке .NET Framework так, как обращалась бы в случае написания программы на C# или другом IL-совместимом языке.

По всей видимости, отсюда и все проблемы — пишем на Delphi .NET, а думаем что это просто Delphi. А ведь в первую очередь это .NET.

Ну автору то простительно — по этой и другим темам ясно, что она новичек.
Но вы то — «эксперт»!

Добавление от 11.01.2013 01:27:

P.S.
Эксперт, Konstantin Mironovich!

Да совсем не внимательны!
Посмотрите на название темы — «C#: File.Exists говорит «да», но File.Delete говорит «файл не найден»»

Автор хоть и пишет на Delphi.NET, но прекрасно понимает, что использует библиотеку .NET Framework.
В отличие ОТ.

20. dozen , 11.01.2013 04:15
as111
Не волнуйся так, ты красивый и член у тебя длиннее всех!
21. antonn , 11.01.2013 10:29
Konstantin Mironovich
сами обратите. у нее дельфи.
шарп у автора, а замечания as111 действительно стоит рассмотреть


22. as111 , 11.01.2013 11:25
dozen
А ты тоже «эксперт», да?
Что, задевает вас старожилов-экспертов, когда сюда иногда заглядывают реальные разработчики?
23. olivenoel , 11.01.2013 12:52
не ругайтесь, «горячие финские парни» Этот проект на c#/.net3.0

Добавление от 11.01.2013 13:30:

Обратите внимание:
http://msdn.microsoft.com/ru-ru/library/system.io.file.delete.aspx
Посмотрите список исключений, метод File.Delete не выдает исключений типа FileNotFoundException.
Наиболее близкое:
«DirectoryNotFoundException Указанный путь недопустим (например, он соответствует неподключенному диску).»

уже обратила. Но вот строка из лога

файл «ELV82-3 v1.5 1002889 2012-08-21 123741.xls» лежит по адресу «C:\eDocTemp\ELV82-3». При его удалении и возникает эксепшн FileNotFoundException — «Datei . konnte nicht gefunden werden». Может ли один и тот же тест сообщения быть для разных эксепшнов? Т.е. есть ли вероятность, что для DirectoryNotFoundException будет такой же код сообщения? Ну и какова вероятность того, что файл будет удален после удаления директории?

у себя на ХР эту ошибку отловить не могу.

цитата: Есть еще:
«IOException
Заданный файл используется.
-или-
Для файла имеется открытый дескриптор, используется операционная система Windows XP или более ранняя версия.Открытый дескриптор мог появиться в результате перечисления каталогов и файлов.Дополнительные сведения см. в разделе Практическое руководство. Перечисление каталогов и файлов.»

файл точно не используется. Если только Directory.GetFiles не создает этих самых хандлов.

цитата: Или
«UnauthorizedAccessException
У вызывающего объекта отсутствует необходимое разрешение.
-или-
path является каталогом.
-или-
Параметр path определяет файл, разрешенный только для чтения.»

точно не может быть, потому что папка создается программно с полным доступом для «Any User».

цитата: И паттерн
«if File.Exists then File.Delete» в корне неверен.

тогда как правильно? Вообще-то, по идее как Directory.GetFiles может найти файл, которого нет? Потому что вот полный код функции, по чистке темпа:

цитата: Тем более, что при вызове File.Delete вам все равно нужно обязательно отлавливать исключения, т.к. это в любом случае операция ввода-вывода в общем случае с непредсказуемыми последствиями,
то заодно и отлавливайте исключение, когда файл не найден.

Добавление от 11.01.2013 13:44:

посмотрела внимательно код, вызывающий эту функцию. К моменту ее вызова этот файл может существовать только если он «слишком долго удаляется». И «полное удаление» происходит уде после File.Exists. Вообще «система ждет» удаления файла по File.Delete? Или ставит что-то в очередь, а потом идет дальше?

24. carrotik , 11.01.2013 13:49
olivenoel

.. а вы не хотите ради проверки поставить после File.Exists какой-нибудь Thread.Sleep() примерно на секундочку и посмотреть результат? .. Если файл будет удаляться, значит, он всё-таки занят чем-то на момент File.Delete . Это, разумеется, не решение задачи, но хоть поймете куда смотреть .

.. а вы не хотите ради проверки поставить после File.Exists какой-нибудь Thread.Sleep() примерно на секундочку и посмотреть результат? .. Если файл будет удаляться, значит, он всё-таки занят чем-то на момент File.Delete . Это, разумеется, не решение задачи, но хоть поймете куда смотреть .

да.. как раз думала в эту сторону.

25. olivenoel , 11.01.2013 13:54
26. as111 , 11.01.2013 14:24
olivenoel
файл «ELV82-3 v1.5 1002889 2012-08-21 123741.xls» лежит по адресу «C:\eDocTemp\ELV82-3». При его удалении и возникает эксепшн FileNotFoundException — «Datei . konnte nicht gefunden werden». Может ли один и тот же тест сообщения быть для разных эксепшнов? Т.е. есть ли вероятность, что для DirectoryNotFoundException будет такой же код сообщения? Ну и какова вероятность того, что файл будет удален после удаления директории?

А вот это уже хуже. Неоднократно замечал, что методы библиотеки классов могут генерировать исключения, не описанные в спецификации. Причем не какие-то редкие и особые — а как в вашем случае (FileNotFoundException).
Общее решение, которое можно предложить — отлавливать все исключения, а не только документированные.
Ну и поскольку FileNotFoundException все-таки может возникнуть, то обрабатывать эту ситуацию в соответствии с тем, как именно, должно реагировать ваше приложение на отсутствие файла.
Хотя это и отличается от «правильного» подхода, который предлагает тот же Рихтер в своей книге, где советует отлавливать исключения только определенных типов — причем не все, которые задокументированы, а только те, которые вы можете обработать так, чтобы программа могла корректно продолжить работу.

Те., делайте примерно так

try
<
File.Delete
>
catch(FileNotFoundException )
<
// do nothing — ничего не делаем
>
catch(DirectoryNotFoundException )
<
// do something
>
catch(XXXException )
<
// do something
>
.
catch (Exception)
<
// show error message and abort
>

цитата:
И паттерн
«if File.Exists then File.Delete» в корне неверен.

тогда как правильно? Вообще-то, по идее как Directory.GetFiles может найти файл, которого нет? Потому что вот полный код функции, по чистке темпа:

Видимо, Directory.GetFiles ищет файлы по алгоритму, схожему с проверкой File.Exists, а вот File.Delete отрабатывается проверку наличия иначе.

Попробую предложить вам следующее:

1. Выполните отладку, как вам предложил carrotik.
Нужно добиться, чтобы при вызове File.Delete исключение FileNotFoundException выдавалось только тогда, когда файла действительно нет.

2. Отладив, вместо
«if File.Exists then File.Delete»
пишите просто «File.Delete».
При этом отлавливайте исключение FileNotFoundException и подавляйте его (т.е. не выводите сообщений об ошибке и т.д.).
В этом случае подавление исключения абсолютно нормально, т.к. для вас этот просто штатная проверка, что файла нет.

3. Труднее, если FileNotFoundException выдается некорректно. Например, файл занят, а выдается FileNotFoundException.
В этом случае можно посоветовать архитектурно организовать иначе работу с файлами.
Потому что даже если вы эмпирические найдете какой-то обходной путь данной ошибки, то на другой машине/версии Windows/сервиспаке могут возникнуть новые ошибки.

цитата: as111:
olivenoel
файл «ELV82-3 v1.5 1002889 2012-08-21 123741.xls» лежит по адресу «C:\eDocTemp\ELV82-3». При его удалении и возникает эксепшн FileNotFoundException — «Datei . konnte nicht gefunden werden». Может ли один и тот же тест сообщения быть для разных эксепшнов? Т.е. есть ли вероятность, что для DirectoryNotFoundException будет такой же код сообщения? Ну и какова вероятность того, что файл будет удален после удаления директории?

А вот это уже хуже. Неоднократно замечал, что методы библиотеки классов могут генерировать исключения, не описанные в спецификации. Причем не какие-то редкие и особые — а как в вашем случае (FileNotFoundException).
Общее решение, которое можно предложить — отлавливать все исключения, а не только документированные.
Ну и поскольку FileNotFoundException все-таки может возникнуть, то обрабатывать эту ситуацию в соответствии с тем, как именно, должно реагировать ваше приложение на отсутствие файла.
Хотя это отличается от «правильного» подхода, который предлагает тот же Рихтер с своей

цитата:
И паттерн
«if File.Exists then File.Delete» в корне неверен.

тогда как правильно? Вообще-то, по идее как Directory.GetFiles может найти файл, которого нет? Потому что вот полный код функции, по чистке темпа:

Видимо, Directory.GetFiles ищет файлы по алгоритму, схожему с проверкой File.Exists, а вот File.Delete отрабатывается проверку наличия иначе.

Попробую предложить вам следующее:

1. Выполните отладку, как вам предложил carrotik.
Нужно добиться, чтобы при вызове File.Delete исключение FileNotFoundException выдавалось только тогда, когда файла действительно нет.

2. Отладив, вместо
«if File.Exists then File.Delete»
пишите просто «File.Delete».
При этом отлавливайте исключение FileNotFoundException и подавляйте его (т.е. не выводите сообщений об ошибке и т.д.).
В этом случае подавление исключения абсолютно нормально, т.к. для вас этот просто штатная проверка, что файла нет.

3. Труднее, если FileNotFoundException выдается некорректно. Например, файл занят, а выдается FileNotFoundException.
В этом случае можно посоветовать архитектурно организовать иначе работу с файлами.
Потому что даже если вы эмпирические найдете какой-то обходной путь данной ошибки, то на другой машине/версии Windows/сервиспаке могут возникнуть новые ошибки.

спасибо большое. Пугает 3. Особенно в свете 2. Если файл.делете выкинет эксепшн, а файл реально будет существовать — это приведет к инконсистентности конечных данных.

27. olivenoel , 11.01.2013 14:34
28. as111 , 11.01.2013 14:50
olivenoel
Я не знаю сути вашего проекта, но на мой взгляд, нужно сразу переходить к другой «архитектуре».
Вплоть до того, что файлы ваши хранить в виде «блобов» в базе данных (для упрощения можно использовать SQL LocalDB Express).
Т.е. такие массовые манипуляции с файловой системой, как ни крути, дают очень большую вероятность постоянных ошибок.

цитата: as111:
olivenoel
Я не знаю сути вашего проекта, но на мой взгляд, нужно сразу переходить к другой «архитектуре».
Вплоть до того, что файлы ваши хранить в виде «блобов» в базе данных (для упрощения можно использовать SQL LocalDB Express).
Т.е. такие массовые манипуляции с файловой системой, как ни крути, дают очень большую вероятность постоянных ошибок.

уже советовала БД. Не хотят. К тому же, по идее, все эти документы должны храниться в САП. Но пока до этого дойдет (((

29. olivenoel , 11.01.2013 14:59
30. Konstantin Mironovich , 11.01.2013 17:44
as111
Где автор писала про Delphi?
очевидно там где код с begin/end. единственный.

Автор явно пишет на Delphi .NET
про это автор умалчивает.

и не надо истерить, тов реальный разработчик. снижает впечатление.

31. dozen , 11.01.2013 18:41
as111

В этом случае подавление исключения абсолютно нормально, т.к. для вас этот просто штатная проверка, что файла нет.

В данном случае подавление исключения — это засовывание головы в песок. Проблема есть, но мы её игнорируем.

1. Файл существует — нельзя подозревать GetFiles() и Exists() в выдаче ложных результатов.
2. Что-то не дает удалять файл. Ошибка FileNotFound — скорее всего, ложно выдаваемая рантаймом в ответ на неожиданный поворот событий.
3. Ошибка проявляется не всегда. Следовательно, ошибка не в жесткой логике кода, а в тайминге или во внешних условиях.

Вариантов я вижу немного:

1. Тайминг — файл еще не закрыт процессом, который его создал. Ошибка, однако, была бы, скорее всего, другая.
2. Внешние условия — *.XLS файл, созданный во временном каталоге, непременно должен быть проверен антивирусом, который, вероятно, на время проверки ни даст его ни открыть, ни удалить (самый простой способ для него — как раз внедрить ошибку «файл не найден»).
3. Race condition: один и тот же каталог используется двумя экземплярами приложения (не зная приложения, не могу предположить, насколько это возможно). C:\eDocTemp\ELV82-3 не выглядит очень случайным.

1. Заставлять убить антивирус — нереалистично, хотя для теста можно попросить отключить на денек (в корпоративных сетях — нереально).
2. В момент возникновения ошибки повторно выдать листинг директории в лог, подождать несколько секунд и повторить попытку (отлогировав результат). Если получится — значит, имеем дело с race condition.
3. Можно попробовать сохранять временные файлы без расширения *.XLS, дабы не привлекать внимания антивируса. Когда закидываем в sharepoint (или куда там) — переименовать. Впрочем, можно получить блокировку на этом шаге, так что шило на мыло.
4. Создавать временный каталог с полностью случайным именем.

P.S. Зачем нужна база данных для работы с файлами — не знаю. Вероятно, от безысходности и неспособности к траблшутингу.

32. as111 , 11.01.2013 20:28
Konstantin Mironovich
Где автор писала про Delphi?
очевидно там где код с begin/end. единственный.

Прочитайте название темы, «эксперт», прочитайте сообщения где автор приводит названия .NET-классов и функций классов (в «обычной» Delphi такого нет), наконец прочитайте сообщение, где автор пишет что проект на «C#/.NET 3.0».

Автор явно пишет на Delphi .NET
про это автор умалчивает.

А вот про это умалчивает, но вот тут вы правильно сделали ссылку на код с begin/end.
Автор пишет на Delphi .NET на .NET 3.0, видимо.

Если уж на то пошло, что с какого бодуна вы решили, что begin/end указывает именно на Delphi? Имена классов и методов не дельфийские, а begin/end много где есть, кроме Delphi.

и не надо истерить, тов реальный разработчик. снижает впечатление.

Тамбовский волк вам товарищ.
Прежде всего не надо хамить, г-н «эксперт». И писать бред на ровном месте тоже не надо.

olivenoel
уже советовала БД. Не хотят. К тому же, по идее, все эти документы должны храниться в САП. Но пока до этого дойдет (((

Значит, придется мучиться с файлами (( Либо учиться продвижению, маркетингу и т.д., и пытаться продавить предложение с базой данных.

dozen
В этом случае подавление исключения абсолютно нормально, т.к. для вас этот просто штатная проверка, что файла нет.

В данном случае подавление исключения — это засовывание головы в песок. Проблема есть, но мы её игнорируем.

Убедительно прошу вас не вырывать мои цитаты из контекста.
Я писал о том, что вначале нужно отладить вызов File.Delete, чтобы он отрабатывал корректно (так же, как File.Exists), и только в этом случае обходиться File.Delete.
И тогда подавление исключение никакое не засовывание головы в песок, а как раз корректная обработка: мы вызываем операцию ввода/вывода, при вызове которой в любом случае нужно ловить исключение, при этом исключение FileNotFound не является «ошибкой».

2. Что-то не дает удалять файл. Ошибка FileNotFound — скорее всего, ложно выдаваемая рантаймом в ответ на неожиданный поворот событий.

Скорее всего, именно так.

P.S. Зачем нужна база данных для работы с файлами — не знаю. Вероятно, от безысходности и неспособности к траблшутингу.

Ну да, базы данных, видимо, придумали для дураков, которые не хотят заниматся траблшутингом.
И блобы то вообще зачем, да? И зачем существуют системы документооборота с базой данных?
А уж зачем придумали FILESTREAM и FILETABLE в SQL Server, вообще непонятно.

Вот ведь здорово — придумать обходное, кривое, некрасивое решение, чтобы обойти один антивирус.
А потом руководство получит «бонус» от конкурентов, и придется делать обходной путь, чтобы обойти другой антивирус.
От красота!

33. dozen , 11.01.2013 21:40
as111

Вот ведь здорово — придумать обходное, кривое, некрасивое решение, чтобы обойти один антивирус.

Еще не подтверждено, что это антивирус.

Пока root cause не найден, предлагать конкретные решения — любительство.

34. as111 , 11.01.2013 21:52
dozen
Мы тут все хотим помочь автору, и вроде все сходятся на том, что File.Exists/Directoty.GetFiles работают в части проверки наличия файла иначе, чем File.Delete.
И вроде конкретных решений тут никто не предлагал.
Все предположения и предложение проверить то или иное как раз касались того, что нужно выяснить, почему File.Delete работает так странно. А уж дальше плясать, исходя из результатов исследования работы File.Delete.
И, кстати, вы дали несколько дельных предположений/советов.

Если вы под конкретными решениями имеете в виду базу данных, то это не конкретное решение, а самое что ни на есть _общее_ решение.
Которое исходит из того, что при активной работе с файловой системой, особенно со множеством файлов, всегда будут ошибки (антивирус, хитрые защиты Windows 7 и т.д.),
которые будут приводить к «инконсистентности конечных данных», которой автор так стремится избежать

Утверждаю, что общим нормальным решением будет именно база данных.

1. Файл существует — нельзя подозревать GetFiles() и Exists() в выдаче ложных результатов.

цитата: 2. Что-то не дает удалять файл. Ошибка FileNotFound — скорее всего, ложно выдаваемая рантаймом в ответ на неожиданный поворот событий.
3. Ошибка проявляется не всегда. Следовательно, ошибка не в жесткой логике кода, а в тайминге или во внешних условиях.

Вариантов я вижу немного:

1. Тайминг — файл еще не закрыт процессом, который его создал. Ошибка, однако, была бы, скорее всего, другая.

не может быть. Потому что этот файл никто не создает и не открывает. Он копируется в другую диру как раз для избежания этой ситуации. И работает потом копия. С ней все нормально. Она потом легко удаляется.

цитата: 2. Внешние условия — *.XLS файл, созданный во временном каталоге, непременно должен быть проверен антивирусом, который, вероятно, на время проверки ни даст его ни открыть, ни удалить (самый простой способ для него — как раз внедрить ошибку «файл не найден»).

это можно вылечить кодом типа:

цитата: 3. Race condition: один и тот же каталог используется двумя экземплярами приложения (не зная приложения, не могу предположить, насколько это возможно). C:\eDocTemp\ELV82-3 не выглядит очень случайным.

он и не есть случайных. С:\eDcoTemp создается программно со всеми нужными пермишнами.

1. Заставлять убить антивирус — нереалистично, хотя для теста можно попросить отключить на денек (в корпоративных сетях — нереально).
2. В момент возникновения ошибки повторно выдать листинг директории в лог, подождать несколько секунд и повторить попытку (отлогировав результат). Если получится — значит, имеем дело с race condition.
3. Можно попробовать сохранять временные файлы без расширения *.XLS, дабы не привлекать внимания антивируса. Когда закидываем в sharepoint (или куда там) — переименовать. Впрочем, можно получить блокировку на этом шаге, так что шило на мыло.
4. Создавать временный каталог с полностью случайным именем.

P.S. Зачем нужна база данных для работы с файлами — не знаю. Вероятно, от безысходности и неспособности к траблшутингу.[/q]

1-4 попробую. Но 3 может сильно осложнить жизнь. Потому что сейчас папка копируется «куда надо» после обработки вызовом хсору на всю папку. Если придется штучно копировать файлы. то ой.

Добавление от 11.01.2013 22:00:

Автор явно пишет на Delphi .NET
про это автор умалчивает.

А вот про это умалчивает, но вот тут вы правильно сделали ссылку на код с begin/end.
Автор пишет на Delphi .NET на .NET 3.0, видимо.

может уже начнете читать? оба? этот проект на c# 2008 .net 3.0. Visual Studio среда разработки. Без Дельфи.

цитата: olivenoel
уже советовала БД. Не хотят. К тому же, по идее, все эти документы должны храниться в САП. Но пока до этого дойдет (((

Значит, придется мучиться с файлами (( Либо учиться продвижению, маркетингу и т.д., и пытаться продавить предложение с базой данных.

вот и мучаюсь. Когда им надоест все это, авось перейдут на SVN какой-нибудь.

цитата:
P.S. Зачем нужна база данных для работы с файлами — не знаю. Вероятно, от безысходности и неспособности к траблшутингу.

Ну да, базы данных, видимо, придумали для дураков, которые не хотят заниматся траблшутингом.
И блобы то вообще зачем, да? И зачем существуют системы документооборота с базой данных?
А уж зачем придумали FILESTREAM и FILETABLE в SQL Server, вообще непонятно.

Вот ведь здорово — придумать обходное, кривое, некрасивое решение, чтобы обойти один антивирус.
А потом руководство получит «бонус» от конкурентов, и придется делать обходной путь, чтобы обойти другой антивирус.
От красота!

от конкурентов никто ничего не получит. И продвигать ничего не надо. Этот проект исключительно для внутреннего применения.

35. olivenoel , 11.01.2013 21:53
36. as111 , 11.01.2013 22:04
olivenoel
Только что вот на что обратил внимание.
Возвратимся на минуту к http://msdn.microsoft.com/ru-ru/library/system.io.file.delete.aspx

Да FileNotFoundException не входит в описание метода,
но зато в описание метода входят:

«DirectoryNotFoundException
Указанный путь недопустим (например, он соответствует неподключенному диску).
IOException
Заданный файл используется.
-или-
Для файла имеется открытый дескриптор, используется операционная система Windows XP или более ранняя версия.Открытый дескриптор мог появиться в результате перечисления каталогов и файлов.Дополнительные сведения см. в разделе Практическое руководство. Перечисление каталогов и файлов.
NotSupportedException
path имеет недопустимый формат.»

Что может из этого следовать?
Вначале ловим DirectoryNotFoundException (потомок IOException),

если ничего не поймали, переходим с ловле
IOException.
А FileNotFoundException тоже потомок IOException.

С формальной точки зрения получается, что любой IOException или его потомок, за исключением DirectoryNotFoundException, является признаком того, что:
«Заданный файл используется.
-или-
Для файла имеется открытый дескриптор, используется операционная система Windows XP или более ранняя версия.Открытый дескриптор мог появиться в результате перечисления каталогов и файлов.Дополнительные сведения см. в разделе Практическое руководство. Перечисление каталогов и файлов.»

Похоже, что действительно ваш файл (если он есть) используется какой-то другой программой (антивирусом?), либо какая-то непонятная вещь с открытым дескриптором — возможно, как раз File.Exists/Directory.GetFiles как и открывают этот дексриптор, но забывают закрыть.
Последнее можно проверить, вызывая просто File.Delete, и проверяя потом, чтобы были удалены те файлы, которые должны были быть удалены.

Добавление от 11.01.2013 22:08:

P.S.
olivenoel
может уже начнете читать? оба? этот проект на c# 2008 .net 3.0. Visual Studio среда разработки. Без Дельфи.

Да я понял)
Просто почему то вы пример кода привели на Delphi.NET. А товарищ за него зацепился. Ну я и пошел ему навстречу — ну да, наверное, Delphi, но не простой, а .NET.
Хотя мне из названия темы и File.Exists/Delete, конечно, все сразу было понятно). Уж не обессудьте за бессмысленные споры.
В первую очередь хочется вам помочь. Вы все-таки насчет открытого дескриптора подумайте.

Добавление от 11.01.2013 22:12:

от конкурентов никто ничего не получит.

Да ну?
Если вы не можете повлиять на решение с базой данных, то почему вы уверены, что руководство по тем или иным причинам не захочет купить другой антивирус? Или у вас так не бывает (нуу. вы понимаете, о чем речь)?

37. dozen , 11.01.2013 22:41
olivenoel

это можно вылечить кодом типа
while (File.Exists(. ))
<
File.Delete(. );
Thread.Sleep(500);
>?

Вылечить — неизвестно, потому что, повторю, root cause не найден еще. С помощью такого кода, однако, можно точнее диагностировать проблему — выводя в лог нужные сообщения.

Это не продакшн код, а траблшутинговый код. Его по изведению проблемы надо будет выкинуть.

Если и в самом деле окажется, что проблема в антивирусе (или в шифраторе диска, или . ), то да, фикс может оказаться именно sleep/retry. Но, повторю, суетиться без знания причин — рано.

Re: DB: В конце концов — FS это тоже БД. И она прекрасно работает для многих-многих приложений. В RDBMS своих заморочек хватает, там, в приципе, тоже DELETE может заканчиваться обломом на ровном месте (скажем, сконфликтовав с транзакцией, начатой каким-нибудь full-text indexer).

Добавление от 11.01.2013 22:51:

Когда им надоест все это, авось перейдут на SVN какой-нибудь.

SVN (как и большинство VCS) с бинарными файлами работают плохо.

от конкурентов никто ничего не получит.

Да ну?
Если вы не можете повлиять на решение с базой данных, то почему вы уверены, что руководство по тем или иным причинам не захочет купить другой антивирус? Или у вас так не бывает (нуу. вы понимаете, о чем речь)?

Да пусть покупают. Я даже за то, чтобы они внедрили какой-нибудь сторонний тул по контролю версий. Тогда я в пятницу вечером буду дома пиво пить, а не ломать голову, почему файл не стирается/пишется или еще что-нибудь. Я ж от этого без работы не останусь. Буду писать программки для автоматизации калибровки, коммуникации и настройки/конфигурации железяк. Еще есть перманентно тормозящий проект по автоматизации САП (для которого мой второй тред рядом) и т.п.

38. olivenoel , 11.01.2013 22:55
39. Imlb , 11.01.2013 23:10
Было: Почему решили, что виноват File.Delete, а не File.Exists?
Выяснил из справки, что File.Exists исключений не вызывает, что в общем-то логично.
Проехали.

olivenoel
не может быть. Потому что этот файл никто не создает и не открывает. Он копируется в другую диру как раз для избежания этой ситуации. И работает потом копия. С ней все нормально. Она потом легко удаляется.

Копия по вашему легко удаляется, а что тогда удаляете вы, исходник?

В конце концов выяснится, что вы в другом месте кода держите этот файл, например в другом потоке.
Чудеса бывают, но редко.

olivenoel
эта копия открывается через Process.Start (т.е. открывается стандратной для этого расширения программой);
копия возможно редактируется и сохраняется под новым именем, содержащим временной штемпель (т.е. в случае редактирования имеем совершенно самостоятельную копию);

Это что за стандартная программа, Excel? Или чья-то самописная?
Если окно этой программы исчезло с экрана, то это не дает 100% гарантии, что от нее не остался какой-нибудь криво написанный поток, которой продолжит держать файлы.
Посмотрите в Диспетчере задач.
В сторону: или где там можно посмотреть программы, работающие под NET.

исходный файл — () — копия файла — () — измененный файл

Начнем с конца:
Измененный файл — нужно сохранить.
Копия файла — легко удаляется.
Исходный файл — тот который нужно удалить

Тогда каким боком тут это:

файл копируется в заранее определенную директорию, на которую у текущего пользователя полные права доступа;
эта копия открывается через Process.Start (т.е. открывается стандратной для этого расширения программой);

То есть речь в первом предложении идет о копии? О втором файле в цепочке? Который и так без проблем удаляется!

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

P.S.
Вы точно нигде и никогда не работаете с файлом, который не получается удалить?

40. Konstantin Mironovich , 12.01.2013 05:47
as111
Прочитайте название темы, «эксперт», прочитайте сообщения где автор приводит названия .NET-классов и функций классов (в «обычной» Delphi такого нет),
автор не пишет на C#.
названия однозначно не говорят что это .NET
точно такие же названия используются в WHS и может еще где.
хотя в силу своего предположительно скудного опыта Вы можете этого не знать.
как и про то, что .NET спроектировал бывший дельфист.

наконец прочитайте сообщение, где автор пишет что проект на «C#/.NET 3.0».
у Вас нарушены причинно-следственные связи. сообщение автора про .NET3.0 было позже моей ремарки про Дельфи.
подумате над этим.
скажу больше. меня сильно интересует упомянутое автором (не часто, но все же; и в основном на Вин7).
почему-то никто на это не обращает особого внимания..

Тамбовский волк вам товарищ.
Прежде всего не надо хамить, г-н «эксперт». И писать бред на ровном месте тоже не надо.

«тамбовский волк» — это обозначение зэка или иного маргинального элемента. я, славабогу, с такими не общаюсь.
постарайтесь не использовать терминов, значения которых не понимаете.
и у Вас комплексы насчет «моего хамства». очевидно что на личности перешли Вы.
то же касается моего «бреда». такие сильные утверждения принято обосновывать.

olivenoel
может уже начнете читать? оба? этот проект на c# 2008 .net 3.0. Visual Studio среда разработки. Без Дельфи.
ага.. ко второй странице ситуация начинает проясняться.
глядишь, через недельку каша в голове уляжется, и получится как всегда.
хотя vertur был где-то прав насчет расстрела..
во всяком случае ответ Process.Start( ) не объясняет насколько корректно завершается процедура работы с файлом.
есть какой-то black-box, который чего-то там редактирует..

больше всего доставляют предложения посмотреть есть ли реально файл в ситуации когда delete его не находит.
а чем смотреть-то будем? все тем же exist.
а погрешность наблюдателя? (ситуация прям как у ядерщиков )
короче, продолжаю поддерживать гипотезу, что дело в прослойке между приложениями и NTFS.

41. dozen , 12.01.2013 05:54
Konstantin Mironovich

больше всего доставляют предложения посмотреть есть ли реально файл в ситуации когда delete его не находит.
а чем смотреть-то будем? все тем же exist.

А таки посмотреть придется, иначе картина происходящего неполна. An extra datapoint, так сказать.

42. Konstantin Mironovich , 12.01.2013 06:08
dozen
А таки посмотреть придется, иначе картина происходящего неполна
фидбек конечно нужен. просто надо понимать чем, как и когда «посмотреть».
развивать не буду, т.к. по моему опыту, к сожалению, вряд ли можно обойтись только бубном и прочими remote control советами.
нужны реальные эксперименты с системой, на которой проблемы.

поэтому сам работаю с 3мя системами с разным железом и кучей виртуалок с разными операционками.

43. as111 , 12.01.2013 11:20
Konstantin Mironovich
Вы продолжаете бредить.
Еще раз посмотрите название темы, и пример кода, где автор вызывает методы .NET-классов.
Такие название могут быть и в других платформах, но обычной Delphi (которая не .NET) их нет.

Либо автор пишет на Delphi.NET (при этом по незнанию приводит название C# как синоним платформы .NET), либо на C# (но зачем то приводит пример кода на Delphi.NET).
Скорее первое.

И про Хейлсберга я знаю, если что.

Если вы кичитесь своим кругозором (Delphi, WHS, Хейлсберг), то должны знать и насчет тамбовского волка.
Когда говорят «тамбовский волк тебе товарищ», то дают понять чтобы вы не обращались к собеседнику «товарищ». Т.е. для вашего собеседника обращение товарищ неприемлемо и/или товарищем он вам не считает.

Насчет сильных утверждений:
Вот вы и обоснуйте ваше сильное утверждение, что якобы автор пишет на Delphi (не .NET).
Вашего утверждения «у нее дельфи.» недостаточно.

Я вашу писанину считаю бредом, и не раз уже писал, почему — посмотрите название темы, приvер кода автора, и ее последующие утверждение про «C# / .NET 3.0», «этот проект на c# 2008 .net 3.0. Visual Studio среда разработки. Без Дельфи. «.
Автор пишет либо на C#, либо на Delphi.NET. Почему путается в том, на чем именно — вот ее и спросите.

Добавление от 12.01.2013 11:36:

И посмотрите вот еще на что:

код
DirectoryInfo dirToClear = new DirectoryInfo(spezDir);
FilesInfo[] files_to_del = dirToClear.GetFiles(«*.*»);
for (int i=0; i 56. Konstantin Mironovich , 13.01.2013 06:36

as111
Вы продолжаете бредить.
так наш реальный программист решил что он к тому же и доктор?
но доктор он явно плохой. что заставляет задуматься и о других его скилах..

Автор пишет либо на C#, либо на Delphi.NET. Почему путается в том, на чем именно
ну так обычно начинают с того, что выясняют детали, а у же потом начинают выдавать кучу бестолкого кода.
впрочем, возможно я уже не в курсе как это нынче принято у реальных..

короче, таки напрягитесь и постарайтесь сосредоточиться на главной задаче — своей помощи автору.
а то она уже начинает сама разбираться в проблеме и скоро решит ее самостоятельно, как это случалось и прежде.
отвлекаясь на внетематическое обсуждение моей скромной персоны Вы рискуете опоздать и остаться не у дел со всем своим опытом реального программиста.

dozen
это все мелочь. переживем.. вот Луговской был.. это настоящий бабуин..
и к тому же реальный программист, как выяснилось.

57. moderator-Kid , 13.01.2013 12:07
Флуд и наезды удалены.

Уважаемые красавцы-бабуины (с), давайте поспокойнее, пожалуйста.

58. antonn , 13.01.2013 13:51
dozen
а чем смотреть-то будем? все тем же exist.
processmonitor
59. dozen , 13.01.2013 20:57
antonn
а чем смотреть-то будем? все тем же exist.
processmonitor

Это был не мой комментарий, но против процесс-монитора я ничего не имею, за исключением того, что наличие файла проще, наверное, проверить в FAR.

60. antonn , 13.01.2013 23:03
я все таки настаиваю не на том чтобы проверить находится ли какой-то файл в директории автора, а посмотреть где проверяется наличие файла программой и какой «комментарий» системы

(как то странно комментарий сработал, автора неверное указал )

61. Konstantin Mironovich , 14.01.2013 09:25
antonn
processmonitor
стандартный TM файлы мониторит до уровня handle (а это кроме файлов куча других объектов).
что конкретно имелось в виду?

глюк форумного движка был. это случается иногда.

62. bislomet , 14.01.2013 12:38
olivenoel
Я обратил внимание на тот факт, что файл-то Ваш — excel-евский.
Т.е. Вы пользуетес скорее всего какой-нибудь excel automation?
А у Вас там не болтается какой-нибудь зомби-процесс Excel-евский, неубитый/неоконченный ранее, который и блокирует доступ к файлу?
Очень похоже, что полученное Вами исключение — наведенное.

цитата: bislomet:
olivenoel
Я обратил внимание на тот факт, что файл-то Ваш — excel-евский.

цитата: Т.е. Вы пользуетес скорее всего какой-нибудь excel automation?

цитата: А у Вас там не болтается какой-нибудь зомби-процесс Excel-евский, неубитый/неоконченный ранее, который и блокирует доступ к файлу?
Очень похоже, что полученное Вами исключение — наведенное.

no. Даже «если бы», то все действия прозводились бы с КОПИЕЙ, для этого она и создается. А проблемы делал ОРИГИНАЛ, который никто не трогает. Т.е. вообще.

После полудня интенсивных тестов на ХР, ошибка так и не всплыла. Короче, непонятно, что это было.

63. olivenoel , 15.01.2013 14:29
64. dozen , 15.01.2013 14:36
olivenoel
После полудня интенсивных тестов на ХР

— Чего ты под фонарём ползаешь?
— Ключи ищу
— А ты их разве тут потерял?
— Нет, но тут лучше видно

Воспроизводить надо на той системе, где ломается. Только когда ясна причина, можно попытаться воссоздать условия на девелоперской машине. А иначе — это тыкание влепую.

65. olivenoel , 15.01.2013 14:50
на целевой машине «затруднен доступ к телу» По софтварной инфраструктуре кроме ОС все одинаковое. На основании имеющегося журнала воспроизводила ситуацию «построчно» — ошибка не появляется. Сделала более подробный журнал. Больше ничего сделать не смогу
66. dozen , 15.01.2013 17:33
olivenoel
Сделала более подробный журнал. Больше ничего сделать не смогу

И не надо. Настоящий индеец терпелив. Добыча придет к ручью.

Но вообще девелопмент надо весть на машинах, аналогичных целевым (разве что помощнее). То есть 7-ку надо бы заиметь.

67. as111 , 15.01.2013 19:47
Лучше искать общее решение, которое будет работать везде.
Хотя с Windows 7 это может не получиться.
Когда она включена в корпоративную сеть с доменом, то на уровне файловой системы у нее вообще паранойя начинается.

Предлагаю все же попробовать протолкнуть иное решение (с базой данных).
Глядишь, покажете себя перед руководством, получите повышение и полномочия.
А то отработаете навыки и в продажники подадитесь. Другие деньги будете поднимать.

68. dozen , 15.01.2013 22:29
as111

Люлей получит, скорее, за необоснованное усложнение (разбазаривание народных денег в период острого международного финансового кризиса).

Да и Дельфи ведь у неё, а Interbase мертв. Толстый троллинг.

69. Gipnoss , 15.01.2013 22:55
dozen
Interbase мертв.
firebird жив
70. dozen , 15.01.2013 23:01
Gipnoss
firebird жив
Undead.
71. as111 , 15.01.2013 23:30
dozen

Люлей получит, скорее, за необоснованное усложнение

С таким настроением слона не продашь.
Надо продавливать и пробивать.

72. dozen , 16.01.2013 02:30
as111
Надо продавливать и пробивать.

Зачем? Кому это надо?


Бизнесу? У него по большей части нормально работает. Для него будет достаточно ошибку подавить и «сделать красиво».
Программеру? Зачем? Есть масса must have проблем. Nice to have могут подождать до новых проектов.

Pick your battles, что называется.

73. as111 , 16.01.2013 11:53
dozen

Зачем? Кому это надо?

Автору. Уметь находить, предлагать и продвигать свои решения.
Для собственного же блага.

Бизнесу? У него по большей части нормально работает. Для него будет достаточно ошибку подавить и «сделать красиво».

Как сказать. Вот часто все «работает». А на самом деле «работающий» программный продукт может тормозить бизнес, сокращать прибыль или даже приносить убытки. Хотя он должен работать как часы и не мешать непосредственно бизнесу.
При этом на его обслуживание уходит куча ресурсов в виде того, что сидят программисты и вместо нового функционала и поиска решений иного уровня (позволяющих упрощать обслуживание, сокращать затраты и даже приносить прибыль бизнесу) занимаются «траблшутингом».

Вот ты же предлагаешь на своем сайте Java-решения?
Почему бы в ситуации автора тоже не начать думать в бизнес-ключе, и поискать аргументы в пользу иного решения, которое, возможно, не только решит проблему с файлами, в и реально поможет бизнесу в чем-то другом? /Мы же не знаем, что у них там за бизнес, и все ли там хорошо, и какие задачи стоят/

74. jooher , 16.01.2013 13:57
as111
сидят программисты и вместо нового функционала и поиска решений иного уровня (позволяющих упрощать обслуживание, сокращать затраты и даже приносить прибыль бизнесу) занимаются «траблшутингом»

Именно такие программисты всегда на хорошем счету на предприятиях, где разработка софта не является основным бизнесом. В отличие от гениев, занимающихся на рабочем месте глобальными изысканиями ради удовлетворения своего ЧСВ, вместо того чтобы быстро устранить конкретный глюк в 1С-модуле, из-за которого бухгалтер не может выдать деньги голодным и злым шахтерам.

75. dozen , 16.01.2013 16:59
as111

которое, возможно, не только решит проблему с файлами, в и реально поможет бизнесу в чем-то другом

Это уже всё сослагательное наклонение.

Неизвестно, есть ли это «что-то другое». Неизвестно даже, насколько серьезна проблема с неудалением файла — может быть, она и внимания не стоит, а olivenoel как раз занимется саморазвитием навыка траблшутинга.

Если я что-то и понял про отношения с бизнесом, то это «не пытайся впарить то, что им не нужно».

В данном конретном случае — есть SAP, куда заливают какие-то Excel-отчеты. Ясно, что SAP — это core, а данная приблуда — это именно приблуда. Все изменения, которые реально могут двинуть вперед бизнес — они на SAP. Внедрение какой-то «улучшенной» архитектуры приблуды будет стоить N килобаксов на разработку и последующее сопровождение, а конечный результат — файлики в SAP — будет такой же. Следовательно — не нужно.

76. olivenoel , 16.01.2013 20:38
Получила «доступ к телу» и кажется решила проблему.

Был еще один вызов из другого места. Там конструкция:

Так вот между получением списка файлов и опросом длины файла проходило какое-то время и файл переставал существовать. Поставила там задержку. И еще ИМХО из-за вставленных тут-и-там дополнительных лог-комментов (и увеличивщимся временем на их выгрузку в файл) по приходу к уже озвученной функции все что надо уже было удалено. Короче время играет значение и имеет роль

вопрос знатокам явы. Читая «Чистый код» пару раз встречала фразу «в джаве выполнения одного и того же участка кода может идти по разным путям» )не дословно. Может тут в дотнете тоже самое?

субъективно — на семерке все происходит дольше. Отсылка предупредительного мэйла занимает пообще секунды три

77. dozen , 16.01.2013 20:51
olivenoel
и кажется решила проблему

Нет, не решила, просто сделала труднее воспроизвести (это я по-русски говорю? не похоже) .

Однако теперь видно, что удаление происходит не немедленно (возможно, не синхронно). Я не виндузятник, так что не могу сказать — эта асинхронность введена на уровне .NET, рантайма VC, самого API винды или драйвера файловой системы.

78. as111 , 16.01.2013 21:35
olivenoel

Так вот между получением списка файлов и опросом длины файла проходило какое-то время и файл переставал существовать.

dozen правильно вам написал, что вы затруднили воспроизведение ошибки, а причина ошибки — в некой асинхронности, место которой еще надо найти (.NET, WinAPI и т.д.).

Но.
Вы помните, я вам писал, что исключение «Файл не найден» в вашем случае не является ошибкой?
/Почитайте Рихтера CLS via C# на досуге — там он очень хорошо написал про разницу между ошибкой и исключением/

Просто пишите
File.Delete(. )
и подавляйте исключение FileNotFoundException.
Подавляйте — потому что в данном конкретном случае в случае если при попытке удаления файл не найден, то корректной обработкой является как раз и является «ничего не делать.»
Скажу больше. Если вам так нравится метод File.Exists, то пишите, вставив проверку наличия файла:

if (File.Exists(. ))
try
<
>
catch (FileNotFoundException)
<
// do nothing
>
// обрабатывать ли другие исключения — зависит от вашей задачи.

Но есть ли смысл вставлять перед блоком try/catch проверку if (File.Exists(. )), если File.Delete все равно делает проверку наличия файла?
В данном случае единственная причина, почему эту проверку можно сделать, заключается в том, что . исключение FileNotFoundException, как я выше показал, не является документированным для метода File.Delete(..) /вообще-то это жесть со стороны MS/
Ну разве что еще для «красоты».

Т.е., вы понимаете, что никакой ошибки на самом деле не происходит у вас?

Скажу вам еще больше.
Чем вы руководствовались, когда писали:
if (File.Exists())
File.Delete()
без обработки исключений при вызове File.Delete.

Ведь файловая система (в отличие от БД) является очень даже внешней средой по отношению к вашей программе, и в общем случае никто и ничто вам не гарантирует, что в момент между выполнением методов
File.Exists и File.Delete файл не исчезнет. Его может прибить/заблокировать/etc антивирус, пользователь, да кто и что угодно.

У вас никакой проблемы с вашей программой вообще нет. Все абсолютно нормально.
Просто пишите
if (File.Exists(. ))
try
<
File.Delete(. )
>
catch (FileNotFoundException)
<
// do nothing
// P.S. Ну если уж так очень хочется, то можете логгировать исключение.
// Только оно вам надо? Лог тоже надо писать в файл, а это все те же исключение при работе с файловой системой.
>

Больше ничего не нужно. Повторюсь, никакой проблемы вообще нет.
Или вы будете пытаться заставить Windows 7 работать как вам хочется, а не как ей надо?
Но как вы этого добьетесь, разрабатывая прикладную программу?

Добавление от 16.01.2013 21:44:

Если я что-то и понял про отношения с бизнесом, то это «не пытайся впарить то, что им не нужно».

Иногда кажется, что весь современный бизнес и экономика заключаются в том, чтобы впарить людям то что им не нужно. И убедить, что этом им нужно.

Вопрос в том, сможете ли вы убедить закзачика/начальство перенести эти файлы в БД SQL или непосредственно в БД SAP?
Если сможете — вы сделаете вполне нужное людям дело (пока они просто об этом не знают!), а если нет — то да, вам будут тыкать в нос, что вы предлагаете не нужное, и если не повезет, то вас не уволят и вы продолжите заниматься траблушутингом.
Вот только я показал выше, что никакой «траблы» тут вообще нет. И вот тут и можно спросить автора, на кой ей руководство будет оплачивать потраченное кол-во человеко-часов?

И вот, кстати. Подумайте — вот что-то реально понадобилось бизнесу, и вы это ему делаете.
А почему это ему раньше не нужно было, а теперь стало нужно?
Получается, некие внешние условия изменились, из-за которые понадобилось что-то новое.
А кто это условия поменял. Да люди.
Просто есть люди, которые меняют действительность, и не спрашивают нужно это или нет. А есть те кто приспосабливается.
Вот я в качестве лирического отступления и посоветовал автору подняться над ситуацией и попробовать свои силы в принципиально ином качестве.

Нет, не решила, просто сделала труднее воспроизвести (это я по-русски говорю? не похоже) .

Однако теперь видно, что удаление происходит не немедленно (возможно, не синхронно). Я не виндузятник, так что не могу сказать — эта асинхронность введена на уровне .NET, рантайма VC, самого API винды или драйвера файловой системы.

а мне собственно все равно, на уровне чего есть асинхронность. Мне главное (пока), чтобы не возникало «повреждения данных» (т.е. инконсистентности бизнес-релевантных файлов). То, что это будет длиться на секунду, или даже пять дольше — в данном случае не критично (собственно копирование файлов xcopy длится около трех секунд). Если им мешает длительность, то пусть переходят к ранее договоренному варианту — никаких «редактирований на лету», только заранее подготовленные файлы.

У этой программы есть более узкое место — никто не хочет даже себе представлять, а что будет, если один и тот же подкаталог с документами, будут редактировать два человека одновременно. Они говорят, что в общем случае есть только ОДИН ответственный, который может вносить изменения.

Но я уже поняла, что «аппетит приходит во время еды». Потому изначально предполагалось, что с помощью этой программы будут транспортироваться ГОТОВЫЕ к сохранению файлы. Потом они захотели их просматривать, потом редактировать — и чтобы программа отслеживала изменения штемпеля последнего сохранения. Что будет потом? Потом придется научиться «проталкивать» свои решения и закрыть эту лавочку нах..н . Пусть как и предполагалось — сохраняют только заранее подготовленные файлы.

79. olivenoel , 16.01.2013 22:00
80. as111 , 16.01.2013 22:08
olivenoel

Еще раз.
Поймите. В случае, если один ответственный, то в исключении FileNotFoundException нет никакой проблемы. Его нужно просто подавить и все.
Учтите, что большинство программистов не понимают смысла исключений. Поэтому и советуют совсем не в ту сторону.

А вот дальше вы сами видите, что файловая система не решает ваших задач, т.к. появляются два «ответственных», и т.д.
Поэтому проталкивайте решение с базой SQL или базой SAP.
Или — миритесь с тем, что вас будут назначать крайней за «инконсистентности бизнес-релевантных файлов» (вы бы вместо умных слов изучили, что такое есть исключения) и дрючить за это. Извиняюсь за экспресс-выражения.

81. olivenoel , 16.01.2013 22:14
as111
И вот, кстати. Подумайте — вот что-то реально понадобилось бизнесу, и вы это ему делаете.
А почему это ему раньше не нужно было, а теперь стало нужно?
Получается, некие внешние условия изменились, из-за которые понадобилось что-то новое.

да не. поменялись как раз внутренние условия. предприятие растет. Со временем появляются ступеньки «количество-качество». Т.е. условно — раньше был человечек, который основную часть рабочего времени сидел и загонял файлики-чертежики-схемочки в САП. Т.к. более-менее квалифицированных в этой области человечков не было, то терпели «загонятеля», да и объемчики были маленькие — грубо говоря сочинялись ПЯТЬ проектов за год. С ростом фирмы и приходом «ориентированности на клиента» проектов стало больше, да и старых, которые нужно поддерживать (менять сопротивление А на конденсатор Б, или аналоговый сигнал на цифровой), поднакопилось. Степень хаоса повысилась, степень ответственности за этот хаос так же возросла. Начальники разных уровней задумались, как избежать влияния хаоса, т.е. снизить кол-во ошибок и «асинхронностей» на этапе попадания тех-документации в САП. Оказалось, что эти ошибки можно было бы давить раньше — на этапе попадания туда, откуда они попадают в САП. Позвали меня. Сказали: сделай чтобы подготовленные файлы с компа ответственного гарантированно копировались на «сервер» с ограниченным доступом. Ответственные стали чесать репу, каких еще плюшек им хотелось бы. И их плюшки стали моей головной болью. Настала моя очередь сказать «вы хотели красную хонду — так получите серебристый бмв»

Добавление от 16.01.2013 22:17:

Еще раз.
Поймите. В случае, если один ответственный, то в исключении FileNotFoundException нет никакой проблемы. Его нужно просто подавить и все.
Учтите, что большинство программистов не понимают смысла исключений. Поэтому и советуют совсем не в ту сторону.

А вот дальше вы сами видите, что файловая система не решает ваших задач, т.к. появляются два «ответственных», и т.д.
Поэтому проталкивайте решение с базой SQL или базой SAP.
Или — миритесь с тем, что вас будут назначать крайней за «инконсистентности бизнес-релевантных файлов» (вы бы вместо умных слов изучили, что такое есть исключения) и дрючить за это. Извиняюсь за экспресс-выражения.

боюсь я его «просто подавить и все». Потому что если в конечной точке станет на один (в лучшем случае) файл больше — возникнет инконсистентность и по закону Мерфи в заказ уйдет неправильный файл. А это стоит деньгов. Так что если уж возникнет ситуация, когда «чего-то наконец-то удалилось», то я лучше подожду пока оно закончится. Проверю еще раз. И в конечной точке будет находится только нужный файл. Во избежание.

82. as111 , 16.01.2013 22:24
Ну и о чем речь?

Произошел переход количества в качество (кстати, насчет первичности вашем случае внешних или внутренних условий, это вопрос; ну да не об этом речь).

И нужно качественное (в философском смысле) решение — в данном случае база SQL с документацией, и эта база должны быть интегрирована в SAP.
Либо сразу все хранить в SAP.

То, о чем вы говорите — это проблема управления конструкторской документацией.
Если системы документооборота еще существуют, то системы управления конструкторской документацией — увы.
Приходится все решать самописно.
У меня один такой проект есть. Так что вы в Германии не одиноки с это проблемой.
В нашем случае это реализовано как база SQL со своей бизнес-логикой, интегрированная с основной ERP на предприятии — 1С (это примерно как SAP у вас).

Добавление от 16.01.2013 22:26:

боюсь я его «просто подавить и все»

Да поймите, File.Delete точно также не ошибается при проверке наличие файла, как и File.Exists/Directory.GetFiles.
Если вылетает FIleNotFoundException — файла действительно уже нет, и точка.

83. carrotik , 17.01.2013 14:05
olivenoel

.. я позволю себе добавить свои пять копеек к предложению as111 о внедрении в проект промежуточного SQL . При правильном планировании базы данных SQL
как раз и будет стоять «на страже консистентности данных», поскольку не позволит вносить данные в неверном формате .. Да, для этого придется добавить кучу проверок на этапе импорта в БД, зато потом у вас решаются все проблемы с многопользовательским просмотром/редактированием (например в гриде в браузере или винформе), импортом в САП, экспортом в любой необходимый формат (включая и Эксел с подключением к базе данных) и т.д .

84. as111 , 17.01.2013 22:03
Добавлю.
В результате размышлений пришел к тому, для для обеспечения «консистентности» данных,
конструкция
if (File.Exists())
try
<
File.Delete();
>
catch (FileNotFoundException)
<
// do nothing
>
неверна.
Ни в коем случае File.Exists неальзя вызывать. Ведь если файл есть, но к нему нет доступа, то File.Exists просто вернет false.
Но файл есть, и должен быть удален. Если удалить не удается, то нужно обработать исключительную ситуацию — как минимум, вывести сообщение об «ошибки», и залоггировать ситуацию.

Никаких «if File.Exists»!

try
<
File.Delete();
>
catch (FileNotFoundException)
<
// do nothing — почему писал выше.
>
catch (DirectoryNotFoundException)
<
// do nothing — по аналогии с FileNotFoundException (нет директории — нет файла)
>
catch (UnauthorizedAccessException e)
<
// Обрабатываем ошибку!
>
catch (IOException e)
<
// Обрабатываем ошибку!
>
catch (PathTooLongException e)
<
// Обрабатываем ошибку!
>

85. carrotik , 18.01.2013 15:23
olivenoel
(собственно копирование файлов xcopy длится около трех секунд).

.. кстати, раз уж вы используете стороннюю утилиту копирования, не хотите попробовать robocopy ? .. Она, скажем так, более «интеллектуальна» что ли .

86. Imlb , 19.01.2013 01:08
dozen
Interbase мертв.
С Interbase’ом все в порядке. В своей нише это отличная СУБД.

as111
Подавляйте — потому что в данном конкретном случае в случае если при попытке удаления файл не найден, то корректной обработкой является как раз и является «ничего не делать.»
Ничего, что файл никто не удаляет, а он уже удалился?
А если через некоторое время он снова появится?

Если речь идет о файлопомойке, то понятно, удалил, не удалил, какая разница, все равно раз в месяц чистить.
Тут же важна консистентность!

87. dozen , 19.01.2013 01:13
Imlb
В своей нише это отличная СУБД.
А какая у него ниша, интересуюсь? Давно не видел живьем, лет так 12.

Ничего, что файл никто не удаляет, а он уже удалился?
А если через некоторое время он снова появится?

Я про страусов уже пел заунывно тут. Не проняло.

88. as111 , 19.01.2013 01:35
Imlb

Научитесь начинать свои предложения без слова «ничего».

Ничего, что автор уже доложила нам, что проверила, и файл действительно не существует на момент File.Delete?

Ничего, что если выбирать между File.Exists и File.Delete, то в плане проверки наличия файла — доверия больше именно File.Delete — почему, уже писал выше. Писали и другие, но делали неверный выбор в пользу File.Exists.

Ничего, что если мы работаем с файловой системой, а не с БД, то в любом случае мы должны ожидать, что файл может быть удален, даже если за миллисекунду до этого мы получили File.Exists==true?
Ничего, что File.Exists выдаст нам false, если файл есть, но нет прав, а как раз во имя консистентности данных мы должны удалить файл, а в случае неудачи (как раз из-за отсутствия прав) хотя бы обработать исключение?
Вы что, реально не понимаете, что как раз конструкция «if (File.Exists) File.Delete)» как раз и приведет к «неконсистентности» данных в случае отсутсвия прав (а отсутствием прав, как и любую жесть мы должны предполагать, т.к. это файловая система, а не БД).

Впрочем, все это я уже писал. Но агрессивным недоучкам не понять. Да ладно вы. Вот автор тоже не понимает. В соседних темах у нее тоже жесть. Вроде просит помощи, а по факту просит обосновать выбор который она уже сделала.

Вас тоже касается.
Но вы вроде разумнее.
Вы прислушайтесь все-таки к моим агрументам про выбор между «if File.Exists File.Delete» и просто «File.Delete».
И про страусов не надо. В данном случае подавление исключения это просто аналог ветвления «if File.Exists File.Delete». Но если файла нет, то в данном случае логике автора делать ничего не надо. Это просто проверка — но именно в данном случае более правильная, из-за особенностей логики работы File.Exists.
Научитесь работать с исключениями.

Если вы про то, что File.Delete может вернуть FileNotFoundException из-за антивируса, то больше проблем наживем, если File.Exists вернет false из-за отсутствия прав (читайте документацию!), а он есть и его надо удалить «консистентсности» ради.

А вот это вообще перл:
«А если через некоторое время он снова появится?»
Проверяем и удаляем то мы сейчас, а не потом (через час или завтра). Вот завтра снова будем вызывать File.Delete.

89. dozen , 19.01.2013 01:59
as111

И про страусов не надо. В данном случае подавление исключения это просто аналог ветвления «if File.Exists File.Delete». Но если файла нет, то в данном случае логике автора делать ничего не надо. Это просто проверка — но именно в данном случае более правильная

Я против подавления ошибки любым способом — хоть if, хоть catch. Против до тех пор, пока root cause не установлен, и не доказано, что он не сможет причинить вреда ни в одном из вариантов.

90. Imlb , 19.01.2013 02:19
dozen
А какая у него ниша, интересуюсь? Давно не видел живьем, лет так 12.
Ниша «установил и работает» без заморочек. Среди промышленных СУБД самое то.
Если речь идет про террабайтные базы данных и навороченные триггеры, то может он и не подходит, но и не всегда такие базы нужны.

Даже скорее наоборот, обычно такие базы не нужны, но ставится MS SQL Server и используется на 0,5%.

as111
Ничего, что если выбирать между File.Exists и File.Delete, то в плане проверки наличия файла — доверия больше именно File.Delete — почему, уже писал выше.
То, что проверка получилась ненужная не спорю, т.к. GetFiles итак получает файлы.
(Однако, то что очевидная ошибка отсутствия файла не прописана в MSDN, добавляет пикантности, не правда ли?
Но не будем развивать эту тему, видимо забыли вписать.)

Но и вы поймите, что от того, что вы правы в своих теоретических изысканиях, конкретная задача не решается.
Есть требование консистентности, а файлы пропадают, то почему не дать по рукам тому, кто ходит и удаляет файлы.
По временным папкам и временным файлам вообще никто не должен лазить.

Автор, на мой взгляд, внятно так и не объяснила цепочку использования файлов, поэтому не берусь судить о необходимости поднятия исключения при такой ошибке.
Список файлов получаем по GetFiles, то есть тупо чистим каталог (если мы работаем с конкретным файлом, почему бы не хранить его имя) и т.д.
Для копирования файлов используется xcopy. В C# нельзя копировать файлы?

Может стоит несколько изменить логику работы и файлы станут не так страшны?

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

91. as111 , 19.01.2013 11:01
dozen
Я против подавления ошибки любым способом — хоть if, хоть catch. Против до тех пор, пока root cause не установлен, и не доказано, что он не сможет причинить вреда ни в одном из вариантов.

Согласен в том, что на этапе отладки, надо устанавливать root cause.
Но потом, если, например, ситуация с отсутствием файла штатная (нет ошибки), то «ошибку» надо подавлять. Хоть if, хоть catch. Вот только в данном случае if (File.Exists) не подходит. Т.к. он проверяет не условие «есть ли файл», а условие «есть ли файл и есть ли у меня на него права».

Но и вы поймите, что от того, что вы правы в своих теоретических изысканиях, конкретная задача не решается.

Да самые что ни на есть практические.

Есть требование консистентности, а файлы пропадают, то почему не дать по рукам тому, кто ходит и удаляет файлы.
По временным папкам и временным файлам вообще никто не должен лазить.

Кто же такой коварный, что умудряется удалять файлы в промежутке времени между операторами File.Exists/Directory.GetFiles и File.Delete?

По вашей логике — тогда, если File.Exists выдал false, тоже надо показывать ошибку? Ведь кто-то успел удалить файл?

Может стоит несколько изменить логику работы и файлы станут не так страшны?

В точку. Автор еще не дошла до ситуации, когда причиной нестабильной работы является файловая система вместо БД.
Пока косяки в в самой программе, в ее архитектуре.

Добавление от 19.01.2013 11:08:

Однако, то что очевидная ошибка отсутствия файла не прописана в MSDN, добавляет пикантности, не правда ли?
Но не будем развивать эту тему, видимо забыли вписать.

Да как раз можно развить.
Во-первых, очень странно, что у многих методов MS в документации не прописаны очевидные и типовые исключения.
Во-вторых, вдвойне странно, что «забыв» вписать исключения в документацию ее к .NET 1.x, так и не вписали и во все последующие документации — в т.ч. и 4.5.

Меня всегда интересовало — почему.

И, кстати, помимо отсутствия типовых исключений методы часто выкидывают исключения, которые генерируются методами, вызываемыми внутри реализации метода, который мы вызываем. А каждый раз позволять системе аварийно завершить программу нельзя.
Поэтому в большинстве случаев (за исключением, когда четко знаешь, что нужно отловить след ситуации — фактически аналог if) приходится перехватывать Exception с выводом Message, имени исключения, InnerException, и только потом останавливать исполнение. Хотя тот же Рихтер так не советует делать. Но теория теорией, а есть практика.

92. Imlb , 19.01.2013 15:56
as111
По вашей логике — тогда, если File.Exists выдал false, тоже надо показывать ошибку?

Исходя из условий каждой конкретной задачи.
В данном случае можно записывать в лог, а может быть и действительно показывать.

Программа не может удалить файл, который с ее точки зрения должен 100 % существовать. Причем удаление файла является обязательным действием, успешность которого является условием завершения текущей операции.
Нет ничего хорошего, что система сама приходит в необходимое для вас состояние (отсутствие файла), ваш, т.е. автора, алгоритм-то не работает!
Т.к. причина пропадания файлов не была установлена, то чем это обернется в будущем предсказать невозможно.

В данном случае есть некоторые сомнения:
1) Необходимость консистентности, насколько это условие влияет на основную цель операции — правку xls-файла.
2) Реализация консистентности. Если мы получаем список файлов по GetFiles, то о каком состоянии системы вообще идет речь? Да, у системы есть какое-то состояние, но мы его нигде не храним и с ним не работаем.

Ваши отсылки к БД не являются панацеей. Excel умеет работать с БД, а если мы работаем с данными в другом формате?
Файловая система не так страшна, как вы ее рисуте. В 99,9 % случаях она обеспечивает то, что от нее требуется.
Активность пользователей, смена прав — это нештатные ситуации и риски, которые возможны при любой другой реализации.

catch (DirectoryNotFoundException)
<
// do nothing — по аналогии с FileNotFoundException (нет директории — нет файла)
>

По вашей логике эта проверка нелепа.
Если каталога не существует, то GetFiles не смог бы вернуть список файлов.

93. dozen , 19.01.2013 19:21
as111

Во-первых, очень странно, что у многих методов MS в документации не прописаны очевидные и типовые исключения. Меня всегда интересовало — почему.

Думаю, геморрой потому что, а пользы — копейки.

Тут ведь вариантов два:

1. Любое исключение означает, что задача не выполнена, надо отваливаться.

Тогда список исключений неважен, просто ловим самое общее, рапортуем и падаем.

2. Некоторые особые ситуации могут быть отловлены и recovered.

Такие ситуации прописаны в требованиях, под них надо создать тесты, в процессе которых и выяснится, какие на самом деле вылетают исключения — и их и отловим. Список исключений может помочь, но он всё равно будет верифицироваться тестами, то есть список nice to have, а не must have. А раз так, то нечего и усилия тратить на детальную документацию.

В жабе вот вынуждены документировать, потому что куча исключений — checked. Это куча возни. Возникло даже течение, в котором все исключения системы наследуются от unchecked (RuntimeException), чтобы со списками дела не иметь. Собственно, я так обычно и делаю.

94. as111 , 19.01.2013 20:43
dozen
В том то и дело, документация по методам .NET — весьма подробная, с кучей продекларированных исключений.
Характерный пример — File.Delete. Прописано много исключений, а про самой очевидное — FileNotFoundException забыли, и так не не добавили.

Возникло даже течение, в котором все исключения системы наследуются от unchecked (RuntimeException), чтобы со списками дела не иметь. Собственно, я так обычно и делаю.

В итоге и в .NET в большинстве случаев программисты ловят System.Exception, и выводят ошибку (как уже писал — за исключением случаев, когда нужно поймать исключение совершенно определенного типа). И я так делаю.
Усовершенствовать тут можно только вот что. Например, выделяем с помощью try блок, в котором могут быть только исключения, связанные, например, с подключением к базе данных и выполнением SQL-команды (а в остальном мы уверены). И тогда можно выводить сообщение, что произошла ошибка при подключении к БД.

Вы когда начинаете писать по делу, получается неплохо, хотя случаются при этом перлы:

Ваши отсылки к БД не являются панацеей. Excel умеет работать с БД, а если мы работаем с данными в другом формате?

Я предлагал не БД организовывать с помощью Excel, а Excel-файлы (и любые другие) хранить в БД.

catch (DirectoryNotFoundException)
<
// do nothing — по аналогии с FileNotFoundException (нет директории — нет файла)
>
По вашей логике эта проверка нелепа.
Если каталога не существует, то GetFiles не смог бы вернуть список файлов.

Проверка не нелепа ни по моей, ни по вашей логике.

По вашей данная проверка нужна вот почему:
вы же считаете, что нужно отлавливать исключение FileNotFound, когда мы удаляем файл, но при этом ожидаем что он должен быть? Те., мы должны поймать за руку того, кто в нарушение соглашений удаляет файл мимо программы уважаемого автора.
Тогда и DirectoryNotFound надо ловить. Вдруг этот некто удалил файл сразу с директорией? По вашей логике, эту ситуацию надо отслеживать, но в этом случае сгенерируется именно DirectoryNotFound, а не FileNotFound. Поэтому DirectoryNotFound — тоже ловить.

По моей логике:
ловить DirectoryNotFound надо, т.к. я считаю что при работе с файловой системой, несмотря на всякие соглашение, нужно быть готовым ко всему.

Файловая система не так страшна, как вы ее рисуте. В 99,9 % случаях она обеспечивает то, что от нее требуется.

10-15 лет назад я тоже так утверждал.

95. Yak , 20.01.2013 10:37

В том то и дело, документация по методам .NET — весьма подробная, с кучей продекларированных исключений.
Характерный пример — File.Delete. Прописано много исключений, а про самой очевидное — FileNotFoundException забыли, и так не не добавили.

Агрессивные переучки читают документацию через строчку?
Откуда Вы вообще взяли, что File.Delete бросает FileNotFoundException ? Из заголовка темы?

Посмотрите с помощью, например, JetBrains dotPeek исходники этих двух функций (я посмотрел).

О, как интересно, исходники Вы тоже через строчку читаете?
96. as111 , 20.01.2013 11:11
Yak

Научитесь не хамить.

Если что, я умею читать «An exception is not thrown if the specified file does not exist.»

Однако, у автора FileNotFoundException вылетает. Возможно, зависит от реализации версии .NET.
Но если автор нам и в этом врет, то вообще непонятно, что мы тут все делаем.

Добавление от 20.01.2013 11:22:

Вы бы лучше задались вопросом, почему куча народу, в т.ч. вполне квалифицированного кинулась давать советы, в документацию вообще никто не глянул, кроме меня.
И почему то кроме меня никто не удосужился спросить тип исключения, вместо той вольной трактовки текстового сообщения, которую нам написала автор.

Так что вы вначале сами научитесь браться за дело, вместо того, чтобы трепаться.

97. Yak , 20.01.2013 12:27
as111
Научитесь не хамить.
О, Вы, смотрю, уже учитесь, поправили свой пост с «Пошел на.» на текущий. Это хороший знак.

Если что, я умею читать «An exception is not thrown if the specified file does not exist.»
Почему же Вы сразу этого не написали, а удивлялись, что FileNotFoundException не отражен в документации? Фраза «An exception is not thrown if the specified file does not exist.» как раз объясняет, почему FileNotFoundException не отражен в списке исключений. Во всех найденных мной описаний File.Delete для различных версий фреймвёрка это указано.

Однако, у автора FileNotFoundException вылетает.
Я поражаюсь, верите автору, который путается между Делфи и C#, и приводящему не реальный код, но не верите MS (хотя у тех тоже косяки бывают, но реже)
Автор, кстати, позже всё-таки показал, что исключение идет от получения свойства Length удаленного файла.


Так что вы вначале сами научитесь браться за дело, вместо того, чтобы трепаться.

Дык, я-то как раз и не трепался, а проверил, что FileNotFoundException не идет от Delete, что вы тут уже 4 страницу обсасываете.

98. as111 , 20.01.2013 12:40
Yak

О, Вы, смотрю, уже учитесь, поправили свой пост с «Пошел на.» на текущий. Это хороший знак.

Ну я вам написал, чтобы вы увидели, а потом убрал, чтобы модераторы не удалили мой пост (т.к. в нем я еще по существу собирался написать).

Почему же Вы сразу этого не написали, а удивлялись, что FileNotFoundException не отражен в документации? Фраза «An exception is not thrown if the specified file does not exist.» как раз объясняет, почему FileNotFoundException не отражен в списке исключений. Во всех найденных мной описаний File.Delete для различных версий фреймвёрка это указано.

Раз вы тоже имеете привычку смотреть документацию, напишу вам как было.
Полез, я, прочитав первый пост автора, смотреть документацию по File.Delete.
И что я вижу? — «An exception is not thrown if the specified file does not exist.»

Отлично, но автор написала исключение какого типа у нее вываливается, и спрашиваю ее об этом. Обратите внимание — хотя я был не первый «помогающий», до этого никто ее не спросил о типе исключения. Она даже Message написала не точно, а своими словами.
Ну тут она и говорит — FileNotFoundException. А я про первую строчку в документации — честно — забыл, т.к. загрузился сумбурными постами автора.
И давай думать — откуда FileNotFoundException? Может, как потомок документированного IOException? Вспомнил, как MS часто не документирует исключение я своим методам. Ну и т.д.

Дык, я-то как раз и не трепался, а проверил, что FileNotFoundException не идет от Delete, что вы тут уже 4 страницу обсасываете.

У меня вопрос к вам — что же вы сами то сразу не написали, что никакого FileNotFound не может быть?
Получается, авторша ввела в заблуждение всех, кроме вас.

Автор, кстати, позже всё-таки показал, что исключение идет от получения свойства Length удаленного файла.

Т.е, как и следовало ожидать, ошибка кроется в в программе авторши? Да вот только, теперь думаю, ну наф разбираться, что там она показала. Если не умеет программировать, пусть хотя бы научится формулировать проблемы, за помощью в решении которых обращается на форум.

100. as111 , 20.01.2013 12:42
Konstantin Mironovich

И что значит сей смайл. У автора Delphi или C#?

Использование file_exists для проверки файла в Uploads

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

Например, если базовое имя является Example_Name, то:
Example_Name_2-LG.jpg – это второе крупное изображение в серии
Example_Name_2_SM.jpg – это соответствующее второе миниатюрное изображение галереи
Example_Name_IN.jpg – это миниатюра индекса, выбранная для представления набора

Используя метаданные и условные выражения PHP, все, что должен сделать клиент, помещается в базовое имя один раз и загружает соответствующие изображения в папку Uploads, а шаблон страницы заполняет пробелы.

Все это прекрасно работает, с одним уловом. Для эскизов имеется семь слотов, а на странице отображаются все миниатюры, даже если в папке «Загружает» меньше семи уменьшенных изображений.

Я хотел бы обернуть каждый миниатюрный div условным file_exists которое использует file_exists для проверки наличия эскизов на самом деле в папке Uploads, так что если именованное изображение не существует в указанном пути к файлу, соответствующий пустой div ( и его гиперссылка) не появится.

Я попытался построить абсолютные пути, используя функцию wp_uploads_dir , а также bloginfo(‘template_directory’) и даже устаревший TEMPLATEPATH , но только преуспел в генерации ошибок PHP. Я предполагаю, что это проблема пути или что-то особенное, я не понимаю о функции PHP file_exists .

Пример вдувания страницы с помощью wp_upload_dir:

Любые предложения оценили.

Solutions Collecting From Web of «Использование file_exists для проверки файла в Uploads»

… вам не нужны все эти echo . Вы ничего не пытаетесь echo . У вас даже есть echo с чередованием конкатенации строк. Оставь все это.

Вероятно, я, скорее всего, проверил бы пост-мета ранее и пропустил вызов file_exists если мета-ключ пуст.

Вы не можете использовать файл url в file_exists() следующим образом:

Вы должны использовать абсолютный путь к файлу , например:

Проверка загруженных файлов с file_exists

У меня есть форма для загрузки данных в моей форме database.The имеет ряд полей ввода текста в пределах формы, номер, текстовое поле и файл (изображения).

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

Мои проверки заключаются в следующем:

Однако, при использовании выше, Исеть будет возвращена истина, даже если файлы не быть uploaded.Upon какой — то прибегая к помощи и глядя на переполнение стека, в частности , Исеть и! Пусто не проходя через проверки для загрузки файлов , где указано , что Исеть будет возвращаю истину из — за $ _FILES будучи суперглобальным, я огляделся в поисках решения и в конечном итоге оседает на file_exists () в качестве замены для Исети () в моем коде.

Мое обоснование для использования file_exists () является то, что файл, который выгружается (представлено) будет сохранены в директории темпа во время процесса загрузки, и если я проверить это временный каталог, я бы таким образом иметь возможность установить, если файл действительно загружен ,

После замены Исеть () с file_exists мой код теперь работает нормально, но мне интересно, если это правильный путь, чтобы продолжить, или если есть какие-либо другие лучшие альтернативы.

Я с нетерпением жду, чтобы любые мнения и / или рекомендации.

file_exists не чувствителен к регистру

столкнулся с проблемой, что винда не чувствительна к регистру имен файлов и директорий
в результате и функция file_exists не чувствительна к регистру

я проверяю с помощью этой функции установлен ли у меня компонент
имя файла компонента имеет вид class.ComponentName.php
в файле класс с именем ComponentName

тут по большей части проблем нет так как php тоже не чувствителен к регистру имен классов и функций

но боюсь, что где-нибудь из-за этого может возникнуть баг

единственное что мне приходит в голову как решение этой проблемы
так это просканить директорию и получить список всех установленных компонентов,
и ориентируясь на этот список уже подгружать компоненты
но это получается жуткая заморочка и мне так делать не хочется

10 ответов

хороший ответ :D

но вопрос в том
как мне сделать, так что бы загрузчик компонентов был чувствителен к регистру?
если не делать, так как я предложил то как

собственно вспомнил пример бага который может возникнуть

// неверное название
$ComponentName = «TeSt»

// .
// загруска компонента упешно отработает
$classname = «class.» . $ComponentName . «.php» ;
if ( file_exists ( ROOT . $path . $classname ) ) <
include_once ( ROOT . $path . $classname ) ;
$SuperClass -> $component = $ComponentName ;
>

// .
// тут будет ошибка Notice объект не найден и метод вызван не будет
// так как методы классов в пыхе чувствительны к регистру
$SuperClass -> test -> run ( ) ;

собственно я впервые столкнулся с этой проблемой
так как всегда передавал правильные имена компонентов
или на стадии его использования имел доступ к имени, под которым он был загружен
в одном из загрузчиков я добавил к параметрам переменную $usename имя, под которым этот компонент будет использоваться

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

приведение, вызываемое имя к нижнему регистру влечет за собой определенные неудобства, так как имя компонента может состоять из одного и более слов то обращаться к компоненту по имени sumelementtorunerconsole не слишком удобно

в принципе проблему можно решить за счет $usename, но эта переменная тоже формируется на верхнем уровне

PS может, я и зря так дергаюсь, но просто как-то дернуло обнаружение этого бага в моей системе

Илон Маск рекомендует:  Шаблон сайта веб технологии HTML, CSS,1 страница
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL