Как узнать имя файла программы с
Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.
Перегрузки
Возвращает имя и расширение файла из пути к файлу, представленного диапазоном символов только для чтения.
Возвращает имя файла и расширение указанной строки пути.
GetFileName(ReadOnlySpan)
Возвращает имя и расширение файла из пути к файлу, представленного диапазоном символов только для чтения.
Параметры
Диапазон только для чтения, содержащий путь, из которого нужно получить имя и расширение файла.
Возвращаемое значение
Символы, следующие за последним символом разделителя каталогов в пути path .
Комментарии
Возвращаемый диапазон только для чтения содержит символы пути, который следует за последним разделителем в path . Если последний символ является path символом разделителя тома или каталога, метод возвращается ReadOnlySpan.Empty. Если path символ разделителя не содержится, метод возвращает path .
См. также раздел
Применяется к
GetFileName(String)
Возвращает имя файла и расширение указанной строки пути.
Параметры
Строка пути, из которой нужно получить имя файла и расширение.
Возвращаемое значение
Символы, следующие за последним символом разделителя каталогов в пути path . Если последним символом параметра path является символ разделения тома или каталога, этот метод возвращает Empty. Если значением параметра path является null , метод возвращает null .
Исключения
Примеры
В следующем примере показано поведение GetFileName метода на классической платформе на основе Windows.
Комментарии
Возвращаемое значение — это null значение, если путь к файлу имеет null значение .
Символы разделителя, используемые для определения начала имени файла, AltDirectorySeparatorCharи DirectorySeparatorChar .
Так как \ это юридическое имя файла в Unix, GetFileName работающее на платформах под управлением Unix, не может правильно вернуть имя файла из пути на основе Windows, например C:\mydirmyfile.ext\, но GetFileName выполнение на платформах на основе Windows может правильно возвращать имя файла из пути на основе Unix, например /tmp/myfile.ext, поэтому поведение GetFileName метода не совпадает с поведением на основе Unix и платформы на основе Windows.
Список распространенных задач ввода-вывода см. в разделе "Общие задачи ввода-вывода".
Перед копированием нужно проверять с чем вы работаете: с каталогом или с файлом, если функция возвращает и пути каталогов.
Владимир, не-а, я тоже сходу подумал, что возвращаются каталоги. Однако там именно имена файлов. Так что обычное Path.GetFileName и Path.GetDirectoryName помогут разбить полный путь на путь и имя файла.
Как вы планируете обрабатывать ситуацию, когда на диске G есть папки folder1 и folder2, в каждой лежит файл 123.ag -- по идее нужно в целевой папке воссоздавать всю структуру папок, верно?
@Сергей что хранится в переменной Namer ? она, я так понимаю, статична ? ибо не вижу, что в коде где-то менялась.
2 ответа 2
С рекурсивным поиском
@Сергей было бы неплохо, если бы вы обозначали задачу. Если вы хотите получить директорию, то ф-я Path.GetDirectoryName() вам поможет, если нужно без названия диска, то можно написать так Path.GetDirectoryName() .Replace("G:\\","")
Я тут подумал: на самом деле если в папке есть две подпапки 1 и 2 и в каждой лежит 123.ag то они запишутся в одно и то же место, один пропадёт. По-хорошему нужно воссоздавать структуру каталогов.
@Сергей Тут есть варианты. Если вы изначально хотите копировать с новыми рандомными/гуидообразными именами, то тут шансы на то, что такой файл уже будет ничтожны. А если вам нужны исходные имена и лишь в случае если они совпадают то переименовывать. То вариантов два: либо заранее проверить имя файла, либо отлавливать IOException -- согласно MSDN это как раз ситуация "файл уже существует". Я бы проверял существование файла, это надёжнее (см. описание эксепшена, там более одного варианта).
И вообще: лучше не копировать, а потом переименовывать -- а сразу подбирать имя, которого не будет. Я же вам разобрал на отдельные переменные и можно собрать их обратно в любом нужном порядке.
@A K я сделал вроде - папки создаются - только не пойму как копировать именно по такому пути - который есть например : есть .az G:\boot\Нужное\Plugin.az- я воссоздал папки по пути temp - G - папки - вот как копировать файл в ту папку,в которой он был на G
@Сергей Нажимаете на своём вопросе кнопку редактировать, вписываете свой новый код в конец вопроса - и тогда попробую ответить. Пока я не могу понять, что и как вы воссоздаёте и что и как вы копируете -- и отвечать вслепую не хочу.
Я хочу получить имя текущей запущенной программы, то есть исполняемое имя программы. В C / C++ вы получаете его от args[0] .
System.AppDomain.CurrentDomain.FriendlyName - возвращает имя файла с расширением (напр. myapp.исполняемый.)
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName - возвращает полный путь и имя файла (например, C:\Examples\Processes\MyApp.исполняемый.) Затем вы можете передать это в System.IO.Path.GetFileName() или System.IO.Path.GetFileNameWithoutExtension() для достижения тех же результатов, как и выше.
System.Diagnostics.Process.GetCurrentProcess() получает текущий запущенный процесс. Вы можете использовать ProcessName свойства, чтобы выяснить имя. Ниже приведен пример консольного приложения.
этого должно хватить:
Это код, который работал для меня:
все приведенные выше примеры дали мне имя процесса с vshost или имя запущенной dll.
возвращает вам System.Reflection.Assembly экземпляр, который имеет все данные, которые вы когда-либо хотели бы знать о текущем приложении. Я думаю, что Location свойство может получить то, что вам нужно конкретно.
даст вам имя файла вашего приложения, как; " MyApplication.EXE-файл"
почему никто не предложил это, его простой.
еще пара вариантов:
- System.Reflection.Assembly.GetExecutingAssembly().GetName().Name
- Path.GetFileName(System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase
- System.Reflection.Assembly.GetEntryAssembly().Location возвращает расположение имени exe, если сборка не загружается из памяти.
- System.Reflection.Assembly.GetEntryAssembly().CodeBase возвращает местоположение в виде URL.
когда вы не уверены или сомневаетесь, бегите по кругу, кричите и кричите.
Я не могу утверждать, что протестировал каждый вариант, но он не делает ничего глупого, как возвращение vhost во время сеансов отладки.
Если вам нужно имя программы для настройки правила брандмауэра, используйте:
это гарантирует, что имя правильно как при отладке в VisualStudio, так и при запуске приложения непосредственно в windows.
Если вы ищете полную информацию о пути вашего исполняемого файла, надежный способ сделать это-использовать следующее:
это устраняет любые проблемы с промежуточными DLL, vshost и т. д.
однако при отладке вы должны быть осторожны, так как этот последний пример может дать исполняемое имя вашего отладчика (в зависимости от того, как вы прикрепляете отладчик), а не исполняемый файл, как и другие примеры.
это то, что вы хотите:
для приложений windows (формы и консоль) я использую это:
добавить ссылку на System.Окна.Формы в VS тогда:
это работает правильно для меня, запускаю ли я фактический исполняемый файл или отладку в VS.
обратите внимание, что он возвращает имя программы без расширения.
супер просто, здесь:
Эти функции осуществляют и завершают поиск для указанных имен файлов:
Remarks
Функция _findfirst предоставляет сведения о первом экземпляре имени файла, соответствующем файлу, указанному в аргументе filespec . В filespec можно использовать любые комбинации подстановочных знаков, которые поддерживаются операционной системой.
Функции возвращают сведения о файле в _finddata_t структуре, которая определена в IO.h . Различные функции в данном семействе используют множество вариантов структуры _finddata_t . Базовая структура _finddata_t содержит следующие элементы:
unsigned attrib
Атрибут файла.
time_t time_create
Время создания файла ( -1L для файловых систем FAT). Это время хранится в формате UTC. Для преобразования в местное время используйте функцию localtime_s .
time_t time_access
Время последнего доступа к файлу ( -1L для файловых систем FAT). Это время хранится в формате UTC. Для преобразования в местное время используйте функцию localtime_s .
time_t time_write
Время последней записи в файл. Это время хранится в формате UTC. Для преобразования в местное время используйте функцию localtime_s .
_fsize_t size
Длина файла в байтах.
char name [ _MAX_PATH ] NULL — завершенное имя сопоставленного файла или каталога без пути.
В файловых системах, которые не поддерживают время создания и последнего доступа к файлу, например системе FAT, поля и time_access всегда -1L имеют значение time_create .
_MAX_PATH определяется в Stdlib.h 260 байт.
Нельзя указать целевые атрибуты (например, _A_RDONLY ), чтобы ограничить операцию поиска. Эти атрибуты возвращаются в attrib поле _finddata_t структуры и могут иметь следующие значения (определенные в IO.h ). Пользователи не должны полагаться на эти значения единственными возможными значениями для attrib поля.
_A_ARCH
Архив. Задается при каждом изменении и очистке файла с помощью BACKUP команды. Значение: 0x20 .
_A_HIDDEN
Скрытый файл. Обычно не отображается DIR в команде, если не используется /AH параметр. Возвращает сведения об обычных файлах и файлах, имеющих этот атрибут. Значение: 0x02 .
_A_NORMAL
Нормальный. У файла не установлены никакие другие атрибуты, чтение и запись возможны без ограничений. Значение: 0x00 .
_A_RDONLY
Только для чтения. Не удается открыть файл для записи, поэтому невозможно создать файл с таким же именем. Значение: 0x01 .
_A_SUBDIR
Подкаталог. Значение: 0x10 .
_A_SYSTEM
Системный файл. Обычно не отображается DIR в команде, если /A не используется параметр или /A:S . Значение: 0x04 .
Функция _findnext находит следующее имя, если таковое имеется, которое соответствует аргументу filespec , указанному в предыдущем вызове функции _findfirst . Аргумент fileinfo должен указывать на структуру, инициализированную предыдущим вызовом функции _findfirst . Если обнаружено соответствие, содержимое структуры fileinfo изменяется, как описано выше. В противном случае он остается без изменений. Функция _findclose закрывает указанный дескриптор поиска и освобождает все связанные ресурсы для функций _findfirst и _findnext . Дескриптор, возвращенный ранее функцией _findfirst или _findnext , необходимо сначала передать в функцию _findclose , чтобы можно было выполнять операции изменения (например, удаление) в каталогах, которые образуют переданные им пути.
Функции _find допускают вложение. Например, если вызов функции _findfirst или _findnext нашел файл, являющийся подкаталогом, новый поиск можно начать другим вызовом функции _findfirst или _findnext .
_wfindfirst и _wfindnext — это версии функций _findfirst и _findnext для расширенных символов. Аргумент Structure версий расширенных символов имеет _wfinddata_t тип данных, который определен в IO.h и в Wchar.h . Поля этого типа данных совпадают с полями типа данных _finddata_t , за исключением того, что в _wfinddata_t поле имени имеет тип wchar_t , а не тип char . В остальном поведение функций _wfindfirst и _wfindnext не отличается от поведения функций _findfirst и _findnext .
Функции _findfirst и _findnext используют 64-разрядный тип времени. Если необходимо использовать прежний 32-разрядный тип времени, можно определить _USE_32BIT_TIME_T . Версии этих функций, в именах которых имеется суффикс 32 , используют 32-разрядный тип времени; версии с суффиксом 64 используют 64-разрядный тип времени.
Функции _findfirst32i64 , _findnext32i64 , _wfindfirst32i64 и _wfindnext32i64 также ведут себя идентично версиям этих функций с 32-разрядным типом времени, за исключением того, что они используют и возвращают 64-разрядные значения длины файлов. Функции _findfirst64i32 , _findnext64i32 , _wfindfirst64i32 и _wfindnext64i32 используют 64-разрядный тип времени, но 32-разрядные значения длины файлов. Эти функции используют соответствующие варианты типа _finddata_t , в которых поля имеют разные типы для времени и размера файла.
_finddata_t фактически представляет собой макрос, который преобразуется в _finddata64i32_t (или _finddata32_t , если определена константа _USE_32BIT_TIME_T ). В следующей таблице приведены сводные сведения об этих вариантах _finddata_t :
Структура | Тип времени | Тип размера файла |
---|---|---|
_finddata_t , _wfinddata_t | __time64_t | _fsize_t |
_finddata32_t , _wfinddata32_t | __time32_t | _fsize_t |
__finddata64_t , __wfinddata64_t | __time64_t | __int64 |
_finddata32i64_t , _wfinddata32i64_t | __time32_t | __int64 |
_finddata64i32_t , _wfinddata64i32_t | __time64_t | _fsize_t |
_fsize_t представляет собой typedef для unsigned long (32 бита).
Например:
FILE* l_fptrConfigFile = fopen(p_strFileName,"r"); //открывается несколько разных файлов
// (разное strFileName)
FILE* l_fptrConfigFile2 = fopen(p_strFileName,"r");
FILE* l_fptrConfigFile3 = fopen(p_strFileName,"r");
FILE* l_fptrConfigFile4 = fopen(p_strFileName,"r");
Далее в программе хочется использовать функцию
void func(FILE* p_fptrConfigFile)
// которая будет выполнять ряд файловых операций (переименование) ПО ИМЕНИ файла, к-рый //передавать в функцию в качестве избыточного параметра не хочется
>
2 Coala: Если бы в структуре FILE присутствовало бы имя файла, я бы этот вопрос не задавал…
2 KAV: Спасибо, этот способ наверно работает - еще не пробовал, но думалось, что из системы эту информацию можно выжать. Предполагал вот такой путь:
FILE* l_fptrConfigFile = fopen(p_strFileName,"r"); // открываем
int handle = fileno(fptrConfigFile); // Получаем файловый дескриптор в программе
long osfHandle = _get_osfhandle(handle); // Получаем файловый дескриптор OS
// Здесь, а м.б. и шагом ранее, с помощью хитрющей ф-ции получаем имя файла от
// операционки, возможно это будет какой-то вызов API.
NTSTATUS
ZwQueryInformationFile(
IN HANDLE FileHandle,
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PVOID FileInformation,
IN ULONG Length,
IN FILE_INFORMATION_CLASS FileInformationClass
);
2 GAGARIN:
Great Thanks, but:
1) MSDN Library:
"The ZwXxx routines provide a set of system entry points that parallel some of the executive's system services. Calling a ZwXxx routine from kernel-mode code results in a call to the corresponding system service.
The system does not check the caller's access rights, nor does it set the previous processor mode to UserMode. Furthermore, before calling a ZwXxx routine, the kernel-mode code must check all the user-supplied parameters for validity."
- это надо переходить в kernel-mode. У меня программа для пользователя, USER-Mode естественно.
2) MSDN Library: "Declared in wdm.h and ntddk.h. Include wdm.h or ntddk.h."
этих headernikov в Buildere нету, походу они должны входить в DDK.
3) Нашел в директории INclude Buildera по поиску текст в файле "QueryInformationFile" ф-цию
KSDDKAPI
NTSTATUS
NTAPI
KsQueryInformationFile(
IN PFILE_OBJECT FileObject,
OUT PVOID FileInformation,
IN ULONG Length,
IN FILE_INFORMATION_CLASS FileInformationClass
);
Но это те же яйца только в профиль: ф-ция предназначена для kernel-mode драйверов устройств виде захвата.
Читайте также: