Ошибка 0x8007007A: Область данных, переданная по системному вызову, слишком мала

[Glashkoff]

Привет. Чем больше пользуюсь Облаком, подключенным через WebDavMailRuCloud, тем чаще сталкиваюсь со странной ошибкой 0x8007007A. Закономерности не нашёл. Решение - добавить/убрать несколько символов из названия файла и тогда файл загружается на сетевой диск нормально. Пример: пытаюсь сохранить в корень диска пустой файл с именем "Файл, который не копируется почему-то никак.txt". В консоли wdmrc появляется такое:

[5]: PROPFIND:http://127.0.0.1:803/%D0%A4%D0%B0%D0%B9%D0%BB%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BD%D0%B5%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D1%83%D0%B5%D1%82%D1%81%D1%8F%20%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%82%D0%BE%20%D0%BD%D0%B8%D0%BA%D0%B0%D0%BA.txt:127.0.0.1:803 - Processing
[5]: HTTP:POST:https://cloud.mail.ru/api/m1/folder?access_token=(тут_токен)&offset=0&limit=2147483647 (107 ms)
[5]: PROPFIND:http://127.0.0.1:803/%D0%A4%D0%B0%D0%B9%D0%BB%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BD%D0%B5%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D1%83%D0%B5%D1%82%D1%81%D1%8F%20%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%82%D0%BE%20%D0%BD%D0%B8%D0%BA%D0%B0%D0%BA.txt:127.0.0.1:803 - Finished (108ms, HTTP 404)
[5]: PROPFIND:http://127.0.0.1:803/:127.0.0.1:803 - Processing
[5]: HTTP:POST:https://cloud.mail.ru/api/m1/folder?access_token=(тут_токен)&offset=0&limit=2147483647 (118 ms)
[5]: PROPFIND:http://127.0.0.1:803/:127.0.0.1:803 - Finished (121ms, HTTP 207)
[5]: PROPFIND:http://127.0.0.1:803/%D0%A4%D0%B0%D0%B9%D0%BB%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BD%D0%B5%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D1%83%D0%B5%D1%82%D1%81%D1%8F%20%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%82%D0%BE%20%D0%BD%D0%B8%D0%BA%D0%B0%D0%BA.txt:127.0.0.1:803 - Processing
[5]: HTTP:POST:https://cloud.mail.ru/api/m1/folder?access_token=(тут_токен)&offset=0&limit=2147483647 (111 ms)
[5]: PROPFIND:http://127.0.0.1:803/%D0%A4%D0%B0%D0%B9%D0%BB%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BD%D0%B5%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D1%83%D0%B5%D1%82%D1%81%D1%8F%20%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%82%D0%BE%20%D0%BD%D0%B8%D0%BA%D0%B0%D0%BA.txt:127.0.0.1:803 - Finished (113ms, HTTP 404)
[5]: PROPFIND:http://127.0.0.1:803/:127.0.0.1:803 - Processing
[5]: Cache hit: /
[5]: PROPFIND:http://127.0.0.1:803/:127.0.0.1:803 - Finished (1ms, HTTP 207)
[4]: PROPFIND:http://127.0.0.1:803/%D0%A4%D0%B0%D0%B9%D0%BB%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BD%D0%B5%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D1%83%D0%B5%D1%82%D1%81%D1%8F%20%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%82%D0%BE%20%D0%BD%D0%B8%D0%BA%D0%B0%D0%BA.txt:127.0.0.1:803 - Processing
[4]: HTTP:POST:https://cloud.mail.ru/api/m1/folder?access_token=(тут_токен)&offset=0&limit=2147483647 (108 ms)
[4]: PROPFIND:http://127.0.0.1:803/%D0%A4%D0%B0%D0%B9%D0%BB%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BD%D0%B5%20%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D1%83%D0%B5%D1%82%D1%81%D1%8F%20%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%82%D0%BE%20%D0%BD%D0%B8%D0%BA%D0%B0%D0%BA.txt:127.0.0.1:803 - Finished (111ms, HTTP 404)
[4]: PROPFIND:http://127.0.0.1:803/:127.0.0.1:803 - Processing
[4]: Cache hit: /
[4]: PROPFIND:http://127.0.0.1:803/:127.0.0.1:803 - Finished (1ms, HTTP 207)

Я полагал, что с системой или учётной записью мейла что-то не так, но вот дошли руки проверить на свежеустановленной WIndows 10 x64 Pro - проблема повторилась. Подключил другие аккаунты - то же самое. Изменение имени помогает. Содержимое, как и размер, могут быть любыми. Уважаемый yar229, у вас воспроизводится эта ошибка?

[yar229]

Да, воспроизводится, если облако подключено диском через Windows net use, если использовать NetDrive или, например, встроенный клиент Total Commander, то все работает.

Думаю, на выходных посмотрю, что можно сделать.

[yar229]

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

В основном, вроде как, этим страдает Windows 10 Fall Creators update

Выход только один - не использовать встроенные средства Windows для работы с WebDAV

[VADemon]

@Glashkoff А ты какой релиз использовал?

Попробуй релиз нацеленный на .Net Core и поставь на всякий случай для net use HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled=1 (REG_DWORD) - ключ реестра появился в Win10 1607.

@yar229 Core проекты переваривают вообще-то по умолчанию длинные пути, .Net 4.6.2 вроде тоже, а для >.Net 4.0 надо выставить <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" />

Информация отсюда https://habrahabr.ru/post/307186/ https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa365239(v=vs.85).aspx

Небольшой ликбез, так как вчера сам темой заинтересовался: Длина одного файла или папки (т.е. объекта) остаётся макс. 255/256 символов. Но длина ВСЕГО пути теперь может занимать 32767 символов. То бишь хоть 10 вложенных папок длиной по 200 символов.

По умолчанию старые версии .Net такие пути не поддерживают, потому что все обёртки над Win32 делают дополнительную проверку длины. Но если использовать Win32 API напрямую, например FileMoveW (Unicode-версия) и начинать путь файла с \\?\, то оказывается это можно было делать с незапамятных времён.

Обычная консоль такие пути не переваривает (но dir файл показывает!), у Explorer'a на Win7 отваливается буквально всё: не открывается файл, не работает толком контекстное меню, перетаскивание и т.п. PowerShell должен вроде с ними работает, но это тот ещё инструмент...

С другой стороны может @yar229 прав и тут не в файловой системе дело, а в длине URL (вместе с http:// и .txt:127.0.0.1:803 == 274 символа). Но в конце концов, если net use подгружает как диск, то там дожно работать это ограничение.

[yar229]

Да,в реестре тоже пробовал ключик поставить, не помогло.

От сервера тут не зависит, цепляемся, например, к Яндекс.Диску - такая же беда.

Windows webclient вообще много непонятных и странных ограничений и кривостей имеет. Понятно, что их появление чем-то обусловлено, но чем дальше - тем печальнее становится.