В нашем приложении у нас есть веб-сервер ASP.NET и сервер API для выполнения различных задач. В этом конкретном рабочем процессе пользователь загружает файл, который веб-сервер копирует в общую сетевую папку для использования сервером заданий. Сервер заданий уведомляется об этом посредством новой строки в таблице MSSQL, которую он сканирует каждую секунду. Где-то в этом году во время интеграционного тестирования этот поток начал случайно давать сбой:
System.IO.IOException: The process cannot access the file '\\a\\b\\c.xlsx' because it is being used by another process."
Локально у разработчиков и QA никогда не возникало этой проблемы, но я предполагаю, что это потому, что их общие папки расположены на соответствующих рабочих машинах. Когда общая папка перемещается из локальной файловой системы в сетевую папку, начинает появляться то же самое исключение.
Я могу воспроизвести случайный случай с помощью этого короткого приложения:
static void Main(string[] args)
{
const string DestinationDirectory = "\\\\10.122.xxx.xxx\\Testing";
var inputPath = args[0];
var filename = Path.GetFileName(inputPath);
var destinationPath = Path.Combine(DestinationDirectory, filename);
Console.WriteLine(filename);
Console.WriteLine("Copying the source file...");
File.Copy(inputPath, destinationPath, true);
Console.WriteLine("Opening the destination file...");
try
{
using var _ = File.Open(destinationPath, FileMode.Open, FileAccess.Read);
Console.WriteLine("Success!");
}
catch (Exception ex)
{
Console.WriteLine(ex);
}
}
Если я запускаю его с помощью этого пакетного сценария, я сталкиваюсь с исключением примерно в 1 раз из 10.
@echo off
for /l %%x in (1, 1, 10) do (
FileShareDemo.exe "C:\a\b\c\myfile"
)
myfile
Copying the source file...
Opening the destination file...
System.IO.IOException: The process cannot access the file '\\10.122.xxx.xxx\Testing\myfile' because it is being used by another process.
at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategyCore(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
at System.IO.File.Open(String path, FileMode mode, FileAccess access)
at FileShareDemo.Program.Main(String[] args)
@echo off
set file=myfile
set source = "C:\a\b\c\%file%"
set destination = "\\10.122.xxx.xxx\Testing\%file%"
for /l %%x in (1, 1, 10) do (
echo Copying...
copy %source% %destination%
echo Reading...
type %destination%
REM powershell -command "Get-Content %destination% -Encoding byte -TotalCount 2"
)
который выполняет те же команды, не вызывает ошибку, поэтому я склонен полагать, что это связано с .NET.
Я пытался использовать утилиту Handle от Microsoft, чтобы найти все дескрипторы, связанные с файлами, до и после открытия файла, но приложение слишком медленно их регистрирует.
АВ @JonasH неинвазивны и не запрещают доступ, по крайней мере, так они устроены, если в этом году что-то не изменилось. С нашей стороны после того, как операционная система хоста файлового ресурса получила различные обновления и обновления, проблема участилась. К сожалению, у меня нет информации о хостах клиента. Они сказали, что это начало происходить с обновлением приложения, которое я только что проверил, версия .NET перешла с 3.1 на 6.0, так что, возможно, что-то в обработке файлов изменилось в более поздних версиях. Слишком много переменных в игре.
По моему опыту, закрытие файла и немедленное его повторное открытие или попытка удаления могут привести к сбою, и я видел это, по крайней мере, начиная с .net 3.5. Я понятия не имею, проблема ли это с AV или какая-то проблема с синхронизацией. Один из подходов — просто подождать несколько мс и повторить попытку.
@JonasH Спасибо за подтверждение. Ранее сегодня мы реализовали единственную 5-секундную повторную попытку, и проблема решена, сообщает QA. Вы можете опубликовать это как ответ.
К вашему сведению, доступ к общим ресурсам сервера через IP довольно неприятен, поскольку обычно это требует менее безопасной аутентификации NTLM.





Кажется, что-то в Windows блокирует новые файлы на малейший момент, и решение этой проблемы — попытаться снова получить доступ к файлу через короткий промежуток времени. Мы установили 5-секундную задержку, и с тех пор проблема исчезла.
Есть ли антивирус, который может сканировать файлы? Были ли какие-либо изменения в конфигурации общего сетевого узла?