Ошибка открытия файла из-за длинного полного имени файла

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Программирование и базы данных (http://forum.oszone.net/forumdisplay.php?f=21)

Ошибка открытия файла из-за длинного полного имени файла

Windows XP и 7, Visual Studio 10 и 12. В программе на C# при открытии файла doc

Код:

doc = word.Documents.Open(ref filename, ref confConv, ref readOnly);

возникает ошибка из-за длинного полного имени файла (более 255 знаков). К сожалению, изменить имя файла я не могу, пользователи засовывают свои файлы в глубокие директории и в имени файла пишут еще и пояснения. Подскажите, пожалуйста, есть ли какие-либо способы обойти ограничение Windows на полное имя файла?

Цитата:

Цитата tumanovalex

есть ли какие-либо способы обойти ограничение Windows на полное имя файла? »

Naming Files, Paths, and Namespaces (Windows)
c# - How to deal with files with a name longer than 259 characters? - Stack Overflow

1. Попробовать использовать префикс «\\?\» в пути.
2. Попробовать перевести длинное имя в короткое формата 8.3 и использовать его (если это допустимо по сценарию).

Что из этого сработает — наверняка сказать не могу. Смотрите, пробуйте.

Спасибо большое за ответ. Попробую.

К сожалению, не получилось решить проблему с длинными именами. Добавление в начало имени файла \\?\ привело к тому, что строки перестали находится в файлах, которые раньше находились. С короткими именами тоже у меня не получилось, наверное, что-то делаю неправильно. Прикрепил проект и архив с директориями, имитирующий длинные имена файлов.

tumanovalex, как я понимаю, Вы пытаетесь работать с Word посредством Automation, и именно там происходит затык/падение при попытке открытия файла с длинным путём, так?

Тогда, насколько я понимаю, увы и ах. С префиксом \\?\ отказываются работать и .Net, и Microsoft Office (по крайней мере, имеющийся у меня 2003-й). И там, и там действует ограничение по MAX_PATH - 1.

С короткими же именами происходит следующее: экземпляр сервера Automation создаётся, документ по указанному «короткому» (8.3) пути открывается, а затем рушится установленная связь клиент Automation — сервер Automation, приложение-клиент Automation падает с ошибкой времени исполнения, а сервер Automation, в данном случае, Microsoft Word, с открытым в нём документом остаётся без видимых окон «висеть» процессом на заднем плане. Короткий пример на VB.Net:

Скрытый текст

Код:

Module Module1



    Sub Main()

        Dim strLongFilePath As String = "C:\Мои проекты\0156\!!! Длинное имя файла\1111111111 1111111111 1111111111 1111111111 1111111111\2222222222 2222222222 2222222222 2222222222 2222222222\3333333333 3333333333 3333333333 3333333333 3333333333\4444444444 4444444444\01234567890123456789012345678901234567890123456789\444_Объединенные ячейки 11111.doc"

        Dim str83FilePath As String



        Dim objFSO As New Scripting.FileSystemObject



        Dim objWord As New Microsoft.Office.Interop.Word.Application

        Dim objDocument As Microsoft.Office.Interop.Word.Document





        str83FilePath = (objFSO.GetFile("\\?\" & strLongFilePath).ShortPath()).Replace("\\?\", "")



        Console.WriteLine("Long path:      " & strLongFilePath.Length & vbTab & "[" & strLongFilePath & "]")

        Console.WriteLine("Short 8.3 path: " & str83FilePath.Length & vbTab & "[" & str83FilePath & "]")



        With objWord

            .Visible = True

            objDocument = .Documents.Open(str83FilePath)

            objDocument.Close()

            .Quit()

        End With



        objWord = Nothing

        objFSO = Nothing

    End Sub



End Module

Возможно, конечно, что это просто у меня пальцы кривые.

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

tumanovalex, разбить filename на путь и имя файла, поменять рабочий каталог, открыть документ по имени без пути?

Busla, я пробовал и так делать. Что .Net, что Microsoft Word радостно обламываются с той же самой ошибкой чересчур длинного пути.