Что такое расположение имени файла и расположение этого процесса

Обновлено: 02.07.2024

Члены большинства типов в пространстве имен System.IO имеют параметр path , который позволяет указать абсолютный или относительный путь к ресурсу в файловой системе. Этот путь передается в API файловой системы Windows. В этом разделе рассматриваются форматы путей к файлам, которые можно использовать в операционных системах Windows.

Традиционные пути DOS

Стандартный путь DOS может состоять из трех компонентов:

Буква тома или диска, после которой следует разделитель томов ( : ).
Имя каталога. Символ разделителя каталогов служит для разделения подкаталогов во внутренней иерархии каталога.
Необязательное имя файла. Символ разделителя каталогов служит для разделения пути к файлу и его имени.

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

Путь	Описание:
C:\Documents\Newsletters\Summer2018.pdf	Абсолютный путь к файлу из корня диска C: .
\Program Files\Custom Utilities\StringFinder.exe	Абсолютный путь из корня текущего диска.
2018\January.xlsx	Относительный путь к файлу в подкаталоге текущего каталога.
..\Publications\TravelBrochure.pdf	Относительный путь к файлу в каталоге, который является одноранговым для текущего каталога.
C:\Projects\apilibrary\apilibrary.sln	Абсолютный путь к файлу из корня диска C: .
C:Projects\apilibrary\apilibrary.sln	Относительный путь из текущего каталога диска C: .

Обратите внимание на различия между двумя последними путями. В обоих случаях задается необязательный описатель тома ( C: ), однако первый путь, в отличие от второго, начинается с корня указанного тома. В результате первый путь является абсолютным из корневого каталога диска C: , тогда как второй — относительным из текущего каталога C: . Использование второй формы пути в тех случаях, когда предполагается наличие первой, является распространенным источником ошибок, связанных с путями к файлам в Windows.

Чтобы определить, является ли путь к файлу полным (такой путь не зависит от текущего каталога и не изменяется при смене текущего каталога), можно вызвать метод Path.IsPathFullyQualified. Обратите внимание, что такой путь может включать сегменты с относительным путем к каталогу ( . и .. ), но при этом по-прежнему будет полным, если разрешенный путь всегда указывает на одно и то же место.

В приведенном ниже примере показано различие между абсолютными и относительными путями. Предполагается, что каталог D:\FY2018\ существует и вы не установили какой-либо текущий каталог для диска D:\ из командной строки перед запуском этого примера.

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

UNC-пути

UNC-пути (универсальное соглашение об именовании) используются для доступа к сетевым ресурсам и имеют следующий формат:

Имя сервера или узла, которому предшествуют символы \\ . В качестве имени сервера может выступать имя компьютера NetBIOS, а также IP-адрес или полное доменное имя (поддерживаются адреса IPv4 и IPv6).
Имя общего ресурса, которое отделяется от имени узла символами \ . Имя сервера и имя общего ресурса в совокупности образуют том.
Имя каталога. Символ разделителя каталогов служит для разделения подкаталогов во внутренней иерархии каталога.
Необязательное имя файла. Символ разделителя каталогов служит для разделения пути к файлу и его имени.

Ниже приводятся некоторые примеры UNC-путей:

Path	Описание
\\system07\C$\	Корневой каталог диска C: на компьютере system07 .
\\Server2\Share\Test\Foo.txt	Файл Foo.txt в тестовом каталоге тома \\Server2\Share .

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

Пути к устройствам DOS

В операционной системе Windows используется унифицированная объектная модель, которая указывает на все ресурсы, включая файлы. Эти пути к объектам доступны из окна консоли и предоставляются на уровень Win32 с использованием специальной папки с символьными ссылками, с которыми сопоставляются устаревшие пути DOS и UNC. Доступ к этой специальной папке осуществляется с использованием синтаксиса пути к устройству DOS, который может иметь одну из приведенных ниже форм:

Помимо использования буквы диска, вы можете указать том с помощью его GUID. Синтаксис будет иметь вид:

Путь к устройству DOS состоит из следующих компонентов:

Описатель пути к устройству ( \\.\ или \\?\ ), который идентифицирует путь как путь к устройству DOS.

Символьная ссылка на "реальный" объект устройства (C: в случае имени диска или Volume в случае GUID тома).

Первый сегмент пути к устройству DOS после описателя пути к устройству идентифицирует том или диск. (Например, \\?\C:\ и \\.\BootPartition\ .)

Для UNC-путей существует специальная ссылка, которая называется UNC . Пример:

Для UNC-путей к устройствам часть сервера или общего сетевого ресурса образует том. Например, в пути \\?\server1\e:\utilities\\filecomparer\ часть server1\utilities представляет сервер или общий сетевой ресурс. Это важно при вызове такого метода, как Path.GetFullPath(String, String) с сегментами с относительным путем к каталогу, поскольку переход дальше тома невозможен.

Пути к устройствами DOS по определению являются полными. Сегменты с относительным путем к каталогу ( . и .. ) в них не допускаются. Они никогда не задаются относительно текущего каталога.

Пример. Способы задать ссылку на один и тот же файл

В следующем примере демонстрируются некоторые способы задать ссылку на файл с использованием API в пространстве имен System.IO. В этом примере создается экземпляр объекта FileInfo и используются его свойства Name и Length, чтобы отобразить имя и длину файла.

Нормализация путей

Практически все передаваемые в API Windows пути нормализуются. При нормализации в Windows выполняются следующие действия:

Идентифицируется путь.
Текущий каталог применяется к неполным (относительным) путям.
Выполняется канонизация разделителей каталогов.
Вычисляются относительные компоненты каталога ( . для текущего и .. для родительского каталога).
Удаляются некоторые символы.

Нормализация осуществляется неявно, но при необходимости вы можете выполнить ее явно, вызвав метод Path.GetFullPath, который создает оболочку для вызова функции GetFullPathName(). Также можно вызвать функцию GetFullPathName() Windows напрямую с помощью P/Invoke.

Идентификация пути

На первом шаге процесса нормализации осуществляется идентификация типа пути. Пути могут относиться к одной из нескольких категорий:

Пути к устройствам: начинаются с двух разделителей и знака вопроса или точки ( \\? или \\. ).
UNC-пути: начинаются с двух разделителей без знака вопроса или точки.
Полные пути DOS: начинаются с буквы диска, разделителя томов и компонентов ( C:\ ).
Пути к устаревшим устройствам ( CON , LPT1 ).
Пути относительно корня текущего диска: начинаются с одного разделителя компонентов ( \ ).
Пути относительно текущего каталога указанного диска: начинаются с буквы диска и разделителя томов, но не содержат разделителя компонентов ( C: ).
Пути относительно текущего каталога: начинаются с любых других символов ( temp\testfile.txt ).

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

Работа с устаревшими устройствами

Если путь указывает на устаревшее устройство DOS, например CON , COM1 или LPT1 , он преобразуется в путь к устройству путем добавления перед ним последовательности \\.\ и возвращается в таком виде.

Путь, который начинается с имени устаревшего устройства, всегда интерпретируется как путь к устаревшему устройству с помощью метода Path.GetFullPath(String). Например, путь к устройству DOS CON.TXT будет выглядеть как \\.\CON , а путь к устройству DOS COM1.TXT\file1.txt будет выглядеть как \\.\COM1 .

Применение текущего каталога

Если путь не является полным, система Windows применяет к нему текущий каталог. К UNC-путям и путям к устройствам текущий каталог не применяется. Также текущий каталог не применяется к полным путям к диску с разделителем C:\ .

Если путь начинается с одного разделителя компонентов, применяется диск текущего каталога. Например, для пути к файлу \utilities и текущего каталога C:\temp\ в результате нормализации будет получен путь C:\utilities .

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

Если путь не начинается с разделителя, применяются текущий диск и текущий каталог. Например, для пути к файлу filecompare и текущего каталога C:\utilities\ в результате будет получен путь C:\utilities\filecompare\ .

Канонизация разделителей

Все символы косой черты ( / ) преобразуются в стандартные разделители Windows, то есть символы обратной косой черты ( \ ). Если они присутствуют, последовательность символов косой черты после первых двух таких символов свертывается в один символ косой черты.

Вычисление относительных компонентов

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

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

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

Родительские каталоги удаляются только в том случае, если они не находятся после корня пути. Корень пути зависит от его типа. Это будет диск ( C:\ ) для путей DOS, сервер или общий сетевой ресурс для UNC-путей ( \\Server\Share ) и префикс пути к устройству для путей к устройствам ( \\?\ или \\.\ ).

Удаление знаков

Помимо удаленных ранее разделителей и относительных сегментов во время нормализации также удаляются некоторые дополнительные знаки:

Если сегмент заканчивается одной точкой, эта точка удаляется. (Сегмент, состоящий из одной или двух точек, нормализуется на предыдущем шаге. Сегмент, состоящий из трех или более точек, не нормализуется и фактически представляет собой допустимое имя файла или каталога.)

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

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

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

Пропуск нормализации

Как правило, любой путь, передаваемый в API Windows передается в функцию GetFullPathName и нормализуется. Существует одно важное исключение: путь к устройству, который начинается со знака вопроса, а не с точки. Если путь не начинается с последовательности \\?\ (обратите внимание на использование канонической формы с обратной косой чертой), он нормализуется.

Зачем нужно пропускать нормализацию? Существует три основных причины:

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

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

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

Пути, начинающиеся с последовательности \\?\ , по-прежнему нормализуются, если явно передать их в функцию GetFullPathName.

Вы можете передавать пути длиной более MAX_PATH символов в функцию GetFullPathName без \\?\ . Она поддерживает пути произвольной длины, которая ограничивается лишь максимальным размером строки, поддерживаемым в Windows.

Регистр символов и файловая система Windows

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

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

Поиск местоположения исходного файла

Процесс очень прост как в Windows, так и в Mac. Однако это зависит от типа файла, в котором вы хотите найти исходное местоположение.

Получить расположение файла в Windows 10

Мы объясним все возможные сценарии на компьютере с Windows 10.

1. Поиск местоположения с помощью свойств файла

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

Сначала щелкните правой кнопкой мыши ярлык приложения Chrome на рабочем столе и выберите «Свойства». Кроме того, вы можете выбрать значок и нажать сочетания клавиш «Alt + Enter».

Откроется окно свойств файла ярлыка.
Сведения о расположении в разделе «Общие» покажут вам расположение файла ярлыка. Это бесполезно, поскольку вы уже знаете, что файл ярлыка находится на вашем рабочем столе.

Щелкните вкладку «Ярлык» и установите флажок «Цель». Здесь вы можете найти расположение исходного файла ярлыка.

Щелкните «Открыть расположение файла», чтобы открыть файл в проводнике. Кроме того, вы можете скопировать целевой путь и сохранить его для дальнейшего использования.

Это полезно, особенно если вы установили приложения на дисках, отличных от C :.

Статьи по Теме:

2. Поиск местоположения с помощью поиска в Windows 10

Введите «край» в поле поиска Windows и щелкните маленькую стрелку вниз, показанную в правой части.

Это покажет некоторые дополнительные параметры и нажмите «Открыть расположение файла».

Теперь вы увидите приложение Edge в проводнике. Однако это будет ярлык Edge, а не исходный файл приложения.

Щелкните правой кнопкой мыши ярлык Edge и откройте окно свойств файла. Как объяснено в приведенном выше методе, вы можете найти местоположение исходного файла в разделе «Ярлык» в поле «Цель».

Однако поле поиска работает по-разному для разных типов файлов. При поиске изображений Windows покажет параметры «Открыть расположение файла» и «Копировать полный путь».

Расположение файлов изображений

Кроме того, вы можете увидеть список «Лучшие приложения», щелкнув поле поиска. Отсюда вы также можете щелкнуть правой кнопкой мыши и открыть расположение файла.

Открыть местоположение из лучших приложений в поиске

3. Получить расположение файла в проводнике.

Приложение File Explorer покажет полный путь к файлу, который вы просматриваете в данный момент. В случае, если вы хотите скопировать местоположение в проводнике, просто щелкните адресную строку. Это покажет полный путь к файлу и нажмите «Control + C», чтобы скопировать местоположение в буфер обмена.

Копировать расположение файла из адресной строки

Получить расположение файла на Mac

Подобно Windows, Mac также предлагает различные методы поиска местоположения файла.

1. Определите местоположение с помощью Get Info

Щелкните файл, местоположение которого нужно найти, и нажмите сочетания клавиш «Command + I». Либо щелкните файл правой кнопкой мыши и выберите параметр «Получить информацию».

Получить данные

Откроется диалоговое окно свойств файла. Проверьте путь к файлу «Исходный» в разделе «Общие».

Исходное местоположение

2. Найдите расположение приложений в Dock.

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

Найти местоположение из Finder

3. Откройте расположение файла в поиске Spotlight.

Путь к файлу в поиске Spotlight

Как в Диспетчере задач отобразить путь к файлу или вредоносной программе, находящейся в автозагрузке Windows 10

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

Большая часть наших читателей знает, что чем больше программ вы устанавливаете на свой ПК, тем дольше он будет загружаться. Происходит это потому, что многие приложения прописывают себя в автозагрузку и стартуют вместе с Windows. Не исключение и вредоносные программы. Иногда в автозапуске так много приложений, что пользователь даже не помнит, когда устанавливал некоторые из них и сомневается в их необходимости. Лечение здесь одно, исключить ненужные программы из автозагрузки (а некоторые даже удалить), после этого OS будет загружаться быстрее. К вирусам применяем немного другой подход - исключаем из автозапуска, перезагружаемся и удаляем, если удалить не получается (выходит ошибка, что файл используется системой), то также с помощью Диспетчера задач останавливаем процессы вредоносной программы и удаляем её.

Я включил ноут пострадавшего и первым делом запустил Диспетчер задач,

затем проследовал в автозагрузку. Сразу отметил для себя файл с именем "Amigo", который задерживал загрузку системы на целых 10 секунд, увидеть это было можно, включив в диспетчере столбец «Влияние на ЦП при запуске». Я щёлкнул на файле правой кнопкой мыши, вызвав меню, но к сожалению отключить или узнать месторасположение вируса система не давала.

Да, существует браузер с таким именем и надо сказать не самого лучшего качества, но в нашем случае файл был заражён вредоносной программой, так как три процесса вируса создавали нагрузку на процессор 99% и именно его пытался удалить антивирус Avast.

Я перешёл на вкладку "Процессы" и снял задачу с вредоносных процессов.

Ноутбук сразу пришёл в норму.

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

Я вернулся в Диспетчер задач и опять перешёл на вкладку "Автозагрузка", щёлкнул правой кнопкой мыши на столбце «Состояние» (можно «Издатель») и в выпадающем меню отметил пункт «Командная строка»,

в результате в столбце "Командная строка" диспетчер задач стал показывать точное местоположение (путь) ко всем программам, находящимся в автозагрузке. Вирус находился в папке:

Казалось бы — что может быть проще, чем работа с файлами в C++. Но отдельные личности поражают своей находчивостью в поиске наихудшего подхода.
Не стоит делать так:

std::string filepath("C:\\тест");
std::ofstream file(filepath.c_str());

Если кратко, то использование не ASCII символов в строковых константах char может привести к печальным последствиям. Я уже обсуждал этот вопрос в посте о кодировках. В данном случае название файла напрямую зависит от кодировки исходника и если кто-то напишет подобное в utf-8, в windows-xp можно получить файл с запрещенными символами, с которым невозможно будет ничего сделать. Можно не использовать не ASCII. Но вы же не можете запретить это пользователю (потоку или БД из которого получен путь). Это же дискриминация по национальному признаку! Срочно исправляемся:

std::wstring filepath= L"C:\тест"
std::ofstream file(filepath.c_str());

Несведущие в стандарте пользователи Visual Studio могут успокоиться, пока нужда не заставит сменить компилятор (точнее STL). И тут начинается…

— «дурацкий gcc» или «дурацкий stlport» не содержит конструктор ofstream::ofstream(wchar_t*)

Дело в том, что текущий стандарт и не предполагает его наличия (не трогаем пока C++0x). Это в чистом виде энтузиазм мелкомягких.

Что же делать?

Использовать стороннюю библиотеку для работы с путями (к примеру boost::filesystem)
Использовать std::locale
Придумывать свой

С третьим вариантом все ясно, с первым тоже ничего сложного:

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

Пользуемся std::locale

Отступление.
Огорчу пользователей mingw: вам придется использовать стороннюю реализацию STL (к примеру stlport) из-за отсутствия в родной правильной поддержки локализации. А точнее, функция std::locale("") всегда возвращает std::locale(«C»), что бы там у вас не стояло. Тот же stlport лишен подобного недостатка. О том как слепить связку mingw+stlport+boost я отписал тут.

Все что нам нужно сделать это следовать простым правилам — с не ASCII работаем в «расширенном» виде. То есть, читаем путь в std::wstring, используя соответствующим образом локализованный поток, а при использовании, сужаем по пользовательской локализации. Эта идея основана на том, что раз пользователь правильно видит символы своего языка в консоли, то его пользовательская локализация знает в какую кодировку надо сузить широкую строку, чтобы правильно интерпретировать путь. Итак, пример. Допустим у нас есть файл в кодировке cp866, содержащий путь. Нам необходимо создать файл по этому пути. Что мы делаем:

Фасеты можно взять на git-hub.

SUMMARY

Если вы используете путь из argv — можете смело с ним работать (пользователь знает что делает). Из «внешней среды» путь получайте с помощью правильно локализованного потока как широкую строку и сужайте ее с помощью пользовательской локализации.

С вопросами можно обращаться:
0. К стандарту
1. К книге Страуструпа (3-е специальное издание, приложение)
2. К документации по mingw.
3. К документации по boost.
4. К посту о фасетах и кодировках.

Всем прямых путей!

UPD: Ну и как правильно заметили Gorthauer87,Migun и naryl в комментариях, обратные слеши и платформо-специфичные пути тоже плохая идея.