error winioerror int32 errorcode string maybefullpath

Guys can some one tell me why i have such error .

i use my App on windows server 2008 and some files need to read / write permission for my application but i have such error so i need to fix that problem and my source is:

2 Answers 2

Yes, the very program that gives you this message may be the program that is locking the file. Make sure to practice good housekeeping by closing each data stream after it has been used.

Where do you close this stream again?

The process cannot access the file xxx because it is being used by another process.

The Microsoft programmer that wrote this message was a trust-hearty soul. He did not want to assume that you got it wrong. When you are debugging your code, that message should however have ended with «is being used by a process». It includes your own.

Also note that you made the same mistake with backupStream. Since you are already using File.ReadAllBytes() to read the file, you might just as well use File.WriteAllBytes() to write it. If you can’t afford the delay then you’ll need to ensure it is closed in the WriteCompeted callback method.

If you already do this, then consider that the file might actually be in use by another process. Which does happen.

Один из моих клиентов получал исключение всякий раз, когда пытался использовать мой продукт. Я получил callstack произошедшего исключения, вершина которого:

Погуглив это, я обнаружил множество сообщения в блоге о том, что это исключение выдается, когда в папке% TEMP% находится более 65535 временных файлов и что решение состоит в том, чтобы просто удалить старые временные файлы. Я могу попросить клиента сделать это, но это может быть только временным решением — что, если они регулярно запускают какое-то другое программное обеспечение, которое делает частые вызовы GetTempFileName, что заставит проблему повторяться снова и снова?

Я не могу просто программно очистить папку% TEMP%, так как это может как-то повредить что-то еще, и я не могу избежать вызова GetTempFileName (и вместо этого использовать мою собственную временную папку), поскольку это не я, а код WPF, который звоню.

Есть ли какое-то постоянное решение для этого?

ОБНОВЛЕНИЕ . Я подтвердил, что проблема, когда папка% TEMP% переполнена файлами журналов, не вызвана моим собственным кодом и должна быть вызвана каким-либо другим сторонним приложением на машина клиента. Я также изучил реализацию Cursor.LoadFromStream , и он, конечно, не виноват — он создает временный файл, но затем удаляет его в —- +: = 2 =: + —- block.

6 ответов

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

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

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

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

• Пусто C:WindowsTemp (для IIS или служб, работающих в LocalSystem аккаунт)
• Или %temp% для локально зарегистрированных пользователей (для меня это C:UsersMyUserNameAppDataLocalTemp ).

С другой стороны, если ваш собственный код выдает это, и вы хотите, чтобы это больше не повторилось:

1. Не используйте System.IO.Path.GetTempFileName ()!

GetTempFileName() — это обертка для Win32 Api двух десятилетий . Он генерирует имена файлов, которые будут очень легко сталкиваться. Он обходит эти коллизии путем интенсивного зацикливания в файловой системе, перебирая возможные имена файлов от «%temp% mp0000.tmp» до «tmpFFFF.tmp» и пропустить уже существующие. Это интенсивный, медленный и откровенно ужасный алгоритм ввода-вывода. Кроме того, использование только 4 шестнадцатеричных символов — вот что делает искусственное ограничение в 65536 файлов перед сбоем.

Альтернатива — генерировать имена файлов, которые не будут конфликтовать. Например, давайте повторно используем логику GUID’s : 32 шестнадцатеричные цифры почти никогда не будут конфликтовать.

Это расширяет лимит с 65 000 до 4 000 000 файлов максимум (теоретически) . Конечно, утечка 65 000 файлов уже ужасна, так что .

1. Не пропускайте временные файлы!

Дважды проверьте ваше приложение на наличие счастливых и несчастных путей (например, неожиданных исключений). Убедитесь, что он корректно удаляет каждый FileStream и удаляет временные файлы в блоках «Наконец».

1. Очистите временную папку

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

• Для глобальных Windows Temp

schtasks /Create /TR «cmd /c call DEL /F /S /Q %^TEMP%» /TN «Delete Global Temp Files» /sc WEEKLY /ST 12:00 /ru system

• Для текущего пользователя:

schtasks /Create /TR «cmd /c call DEL /F /S /Q %^TEMP%» /TN «Delete %username% Temp Files» /sc WEEKLY /ST 12:00

Вот код, который я использовал в конце и поместил в начале кода инициализации моего приложения, перед любыми вызовами Cursor.LoadFromStream происходит:

1. Правильный. Определите, какое приложение создает столько временных файлов, а не удаляя их. Утилиты, такие как Process monitor должен вам помочь. Затем либо исправьте приложение, либо выбросьте его. И да, это может быть ваше приложение. Вот почему я рекомендую вам обнаружить источник зла.
2. Самый простой. Используйте свой собственный временный каталог. Это не поможет, если файлы создаются из вашего кода.
3. Самый уродливый. Очистите временную директорию от вашего приложения. Вы абсолютно правы в отношении последствий — вы можете сломать другое приложение.

Как и Sayse , вы можете попытаться установить переменную среды% TEMP% при запуске приложения.

Для всех, кто столкнулся с этой проблемой и не может найти переполненную временную папку — Проверьте папку «C: /Windows /Temp». Очистка этой папки решила мои проблемы.

I have an issue with datacap 9.1 traveldocs application.

I have a rule to scan input from email(Reading Email ), which I have added in Vscan Task profile and now I have Vscan, Reading Email tasks in Vscan task profile. And added the rule to Traveldocs document hierarchy at batch level.

From Vscan log, I can obser that its able to scan image from mail. But the problem is if I have image in images folders of my traveldocs application and also an email with attachment in my inbox then Vscan task profile is just scanning image from images folder and writing successfully to Batch folder, but scanning from email getting the below mentioned error.

IMAGEFILE C:DatacapTravelDocsatches20180322.000008TM000001.tif 11:35:24.909 (0) Error: failed to write IMAGEFILEC:DatacapTravelDocsatches20180322.000008TM000001.tif Exception: System.IO.IOException: The file ‘C:DatacapTravelDocsatches20180322.000008TM000001.tif’ already exists. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath

If I have no images in images folder but a mail in inbox then its working fine. At a time I am not able to write two inputs to batch folder.

how can I resolve this error. Any thoughts will be really helpful.

Этим пользователям нравится это

1 Ответ

• Отсортировать:

Ответ от yanglo (1141) | 22/03/18 09:11

Please show or provide your respective task, task profile, ruleset(s), rule(s), function(s) and action(s). Even with any log, please provide the full file. Otherwise, I’m afraid no one is able to really tell what’s going on.

The following is what I see either unclear or problematic — again, speculation is the only choice without seeing details. You said:

I have a rule to scan input from email(Reading Email ), which I have added in Vscan Task profile and now I have Vscan, Reading Email tasks in Vscan task profile.

It’s no problem if you use VScan task profile to import emails, even though it’s misleading by the name for the task or task profile.

I have image in images folders of my traveldocs application and also an email with attachment in my inbox then Vscan task profile is just scanning image from images folder and writing successfully to Batch folder, but scanning from email getting the below mentioned error.

It seems you have, at the very least, some actions in this task/task profile to import image files from a folder. If you have two separate functions, one for importing files and another for importing emails, in the same rule — because you cannot have two separate rules attached to the same DCO object in the same ruleset, then it’s sound logically.

However, as you may or may not know, Datacap rules work in its own way during run-time, which is that, if a function is successful, all following functions will be skipped, unless you have GoToNextFunction() action in place.

In your case, only one import, either image file or email, instead of both, would work, which matches the end result or behavior of the problem as described. However, again, we need to see details to understand or confirm it, esp. regarding the errors in the log.