использование WinAPI(kernel32.dll) для работы с файлами,pipe
использование WinAPI(kernel32.dll) для работы с файлами,pipe
Проблема с использованием инструментария Windows API для работы с файлами.
Изначально стояла задача использовать механизм PIPE (Именованный канал, труба - по сути файл с путем \\.\pipe\<имя_канала>) для быстрого межзадачного обмена в LabView,
так как стандартные кубики LabView по работе с файлами не умеют работать с путями типа "\\.\pipe\<имя_канала>" было решено использовать WinAPI, а точнее библиотеку kernel32.dll, для работы с такими файлами (вообще с именованными каналами работают простые функции типа CreateFile, WriteFile, ReadFile, CloseHandle а так же спец.функции типа CreateNamedPipe и т.д.).
Но работа встала на этапе попыток использования WinAPI для ПРОСТЫХ файлов (d:\123.txt), файл создается (createfile), но в него ничего не могу записать(writefile)/считать(readfile) - ошибка 1097 использования dll.
Описание использования CreateFile:
MSDN_createfile
Описание CreateFile на русском
MSDN_writefile
Описание WriteFile на русском
подробные настройки входов/выходов dll смотрите в probe2.vi
думаю, что ошибка в настройке входов у writefile - lpbuffer, по описанию функции имеет тип LPCVOID (Указатель на буфер, содержащий данные, которые будут записаны в файл.)
я настроил как array, u8, 1, array data pointer также перепробовал всевозможные варианты настройки этого и других параметров.
Основной вопрос в использовании функции WriteFile библиотеки kernel32.dll инструментария Windows API, кто пользовался, кто сталкивался?
Изначально стояла задача использовать механизм PIPE (Именованный канал, труба - по сути файл с путем \\.\pipe\<имя_канала>) для быстрого межзадачного обмена в LabView,
так как стандартные кубики LabView по работе с файлами не умеют работать с путями типа "\\.\pipe\<имя_канала>" было решено использовать WinAPI, а точнее библиотеку kernel32.dll, для работы с такими файлами (вообще с именованными каналами работают простые функции типа CreateFile, WriteFile, ReadFile, CloseHandle а так же спец.функции типа CreateNamedPipe и т.д.).
Но работа встала на этапе попыток использования WinAPI для ПРОСТЫХ файлов (d:\123.txt), файл создается (createfile), но в него ничего не могу записать(writefile)/считать(readfile) - ошибка 1097 использования dll.
Описание использования CreateFile:
MSDN_createfile
Описание CreateFile на русском
MSDN_writefile
Описание WriteFile на русском
подробные настройки входов/выходов dll смотрите в probe2.vi
думаю, что ошибка в настройке входов у writefile - lpbuffer, по описанию функции имеет тип LPCVOID (Указатель на буфер, содержащий данные, которые будут записаны в файл.)
я настроил как array, u8, 1, array data pointer также перепробовал всевозможные варианты настройки этого и других параметров.
Основной вопрос в использовании функции WriteFile библиотеки kernel32.dll инструментария Windows API, кто пользовался, кто сталкивался?
- Вложения
-
- probe2.vi
- PROBE2.VI
- (12.17 КБ) 274 скачивания
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Дополнение: версия LabView 8.6.1f1, такая же проблема и на LabView 2011
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Читайте внимательно описание функции WriteFile. Вы забыли 2 параметра. Вот так работает:
- Вложения
-
- probe2_corrected.vi
- (15.05 КБ) 314 скачиваний
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows
-
Chupakabra
- professional
- Сообщения: 360
- Зарегистрирован: 21 янв 2009, 10:50
- Награды: 1
- Версия LabVIEW: 2015
- Откуда: Москва
- Поблагодарили: 4 раза
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
И что, будет работать быстрее чем существующие механизмы обмена?для быстрого межзадачного обмена в LabView
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
В моей практике win32 pipes самый низколатентный спсоб обмена информацией между и .net приложениями
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Спасибо, помогло! только с pipe всё тоже самое не работает (путем замены пути на \\.\pipe\name) - ошибок нет, но и не пишет в канал..mzu2006 писал(а):Читайте внимательно описание функции WriteFile. Вы забыли 2 параметра. Вот так работает:
для межзадачного обмена пока пользуюсь файлами на RAM диске, работает с циклом 1 мс. Стандартные механизмы типа shared variable более тормозные, а других и не знаю
(при условии, что нужен доступ не только из Labview-программ)
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Проверьте handle на равенство INVALID_HANDLE + Соответствующий GetLastError. Кроме того, а pipe предварительно создана через CreateNamedPipe?
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows
-
- assistant
- Сообщения: 126
- Зарегистрирован: 06 ноя 2011, 14:10
- Версия LabVIEW: 2012-2016
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Доброго времени суток,
kernel32.dll не работает больше на win 10-64bit с LabVIEW-2015 32/64bit. Тот же код работает на др. машине с win 8.1-64bit с LabVIEW-2015 32/64bit.
Сталкивался уже кто нибудь с этой проблемой? Есть у кого идеи решения?
Большая просьба попробовать на др. версиях LabVIEW под win 10-64bit.
SubVI сохранил для LabVIEW 11.
kernel32.dll не работает больше на win 10-64bit с LabVIEW-2015 32/64bit. Тот же код работает на др. машине с win 8.1-64bit с LabVIEW-2015 32/64bit.
Сталкивался уже кто нибудь с этой проблемой? Есть у кого идеи решения?
Большая просьба попробовать на др. версиях LabVIEW под win 10-64bit.
SubVI сохранил для LabVIEW 11.
- Вложения
-
- Create_SetPoint_Read_Close_kernel32dll.vi
- (9.1 КБ) 235 скачиваний
-
ladik
- developer
- Сообщения: 275
- Зарегистрирован: 18 ноя 2014, 11:45
- Награды: 1
- Версия LabVIEW: 2015, 2019
- Откуда: Екатеринбург
- Благодарил (а): 4 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Всё работает. Только пути в CLFN поменял.
Дорогу осилит идущий.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Igor_G,
dadreamer писал(а):если используются стандартые системные библиотеки (kernel32, user32 и т.д.), то в CLFN нужно указывать не путь к ним, а только имя! Это обеспечит совместимость с любой версией ОС, где будет использоваться программа.
-
- assistant
- Сообщения: 126
- Зарегистрирован: 06 ноя 2011, 14:10
- Версия LabVIEW: 2012-2016
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Спасибо за тест и советы,
с путём к dll был мой эксперимент. Извиняюсь что в этом виде отправил VI.
Похоже что проблема заключается все таки в другом.
Права доступа к файлу под Win 10 на др. рartition. (см. screenshot). Read-only на папку поставил Win10 Pro сам (возможно как default).
Первый вопрос: Какая разница? Это должно быть по идее все равно, или нет? Я ведь только читать файл хочу. Права на чтение имеют все, даже стандартный пользователь...
Хотелось бы сразу исключить дискуссии на тему кто виноват. Важно, что если это случилось у меня, то может случиться и у клиентов.
- Я работаю как администратор (см. screenshot права доступа) и несмотря на это LabVIEW-2015 через kernel32 не могла ПРОЧИТАТь файл!? - Точнее говоря, dll отрабатывают, как будто нормально (не выдавая ни какой ошибки), но в результате выдаёт фальшивый результат! Как такую ошибку у клиентов найти?
"Решение проблемы" - ручками разрешил авторизованному пользователю полный доступ к папке. После этого все заработало нормально.
Второй вопрос: Почему? Система и администратор имеют права полного доступа. Я работаю, как админ. Как понятно это на самом деле не решение проблемы. Ждать пока Microsoft или NI решат это проблему тоже не выход. Третий вопрос: Что делать?
(1) Идеальное решение было бы - (а) проверка файла/папки на read-only. (б) снять read-only с файла/папки на время доступа LabVIEW и/или программы написанной на LabVIEW. (в) вернуть установки на файл/папку после завершения доступа или закрытия программы.
(2) - (а) проверка файла/папки на read-only. (б) выдача сообщения пользователю о активном read-only.
P.S.: К сожалению пользователь работает обычно без прав админа. Поэтому он не сможет изменить доступ к файлу/папке. Т.е. будет знать почему не работает и не больше. :о(
Есть идеи?
с путём к dll был мой эксперимент. Извиняюсь что в этом виде отправил VI.
Похоже что проблема заключается все таки в другом.
Права доступа к файлу под Win 10 на др. рartition. (см. screenshot). Read-only на папку поставил Win10 Pro сам (возможно как default).
Первый вопрос: Какая разница? Это должно быть по идее все равно, или нет? Я ведь только читать файл хочу. Права на чтение имеют все, даже стандартный пользователь...
Хотелось бы сразу исключить дискуссии на тему кто виноват. Важно, что если это случилось у меня, то может случиться и у клиентов.
- Я работаю как администратор (см. screenshot права доступа) и несмотря на это LabVIEW-2015 через kernel32 не могла ПРОЧИТАТь файл!? - Точнее говоря, dll отрабатывают, как будто нормально (не выдавая ни какой ошибки), но в результате выдаёт фальшивый результат! Как такую ошибку у клиентов найти?
"Решение проблемы" - ручками разрешил авторизованному пользователю полный доступ к папке. После этого все заработало нормально.
Второй вопрос: Почему? Система и администратор имеют права полного доступа. Я работаю, как админ. Как понятно это на самом деле не решение проблемы. Ждать пока Microsoft или NI решат это проблему тоже не выход. Третий вопрос: Что делать?
(1) Идеальное решение было бы - (а) проверка файла/папки на read-only. (б) снять read-only с файла/папки на время доступа LabVIEW и/или программы написанной на LabVIEW. (в) вернуть установки на файл/папку после завершения доступа или закрытия программы.
(2) - (а) проверка файла/папки на read-only. (б) выдача сообщения пользователю о активном read-only.
P.S.: К сожалению пользователь работает обычно без прав админа. Поэтому он не сможет изменить доступ к файлу/папке. Т.е. будет знать почему не работает и не больше. :о(
Есть идеи?
-
- assistant
- Сообщения: 126
- Зарегистрирован: 06 ноя 2011, 14:10
- Версия LabVIEW: 2012-2016
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Нашел в нете, что ,то что я только на win-10 встретил было у других и на win-8.1.
Так можно сбросить read-only с помощью "get Permissions" l;о) Тут источник и объяснение (на нем.).
http://www.labviewforum.de/Thread-Schreibschutz-auf-Datei-aufheben
Так можно сбросить read-only с помощью "get Permissions" l;о) Тут источник и объяснение (на нем.).
http://www.labviewforum.de/Thread-Schreibschutz-auf-Datei-aufheben
-
- assistant
- Сообщения: 126
- Зарегистрирован: 06 ноя 2011, 14:10
- Версия LabVIEW: 2012-2016
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
SubVI сохранил для LabVIEW 11.
- Вложения
-
- Create_SetPoint_Read_Close_kernel32dll_Read-only_free.vi
- (11.15 КБ) 233 скачивания
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: использование WinAPI(kernel32.dll) для работы с файлами,
Без разницы. Если собираетесь только читать файл, то можете хоть какой атрибут ставить. Если не задано специальных политик для ограничения доступа к файлу, то юзер из-под ограниченной учётки спокойно сможет прочитать файл, хоть где, хоть даже в системном каталоге Windows.Igor_G писал(а):Первый вопрос: Какая разница? Это должно быть по идее все равно, или нет? Я ведь только читать файл хочу. Права на чтение имеют все, даже стандартный пользователь...
А вы внимательно посмотрите на свой код и сверьте его с тем, что опубликован в статьях по работе с CreateFile / Read/WriteFile / CloseHandle. Во-первых, вы выставили параметр dwDesiredAccess в GENERIC_ALL (0x10000000L), то есть на чтение и на запись одновременно. А файл у вас только для чтения. После вызова CreateFile как всякая порядочная функция сообщает вам об ошибке INVALID_HANDLE_VALUE (0xFFFFFFFF = -1d). Далее, по-хорошему, нужно было бы проверить результат и при возникновении ошибки выполнить GetLastError и проанализировать ошибку. У вас же хэндл файла без всякого анализа отправляется дальше на прочие функции, даже если он -1. Потому и ReadFile, например, ничего не сможет прочитать по такому хэндлу.Igor_G писал(а):- Я работаю как администратор (см. screenshot права доступа) и несмотря на это LabVIEW-2015 через kernel32 не могла ПРОЧИТАТь файл!?
Вот, даже в этом топике mzu2006 написал:
mzu2006 писал(а):Проверьте handle на равенство INVALID_HANDLE + Соответствующий GetLastError.
Вероятно, что поменялись атрибуты файла, и снялся флажок "только для чтения". Но суть в том, что права юзера сейчас не трогаем, если юзер ограниченный, то читать-то он всё равно может, даже если не является владельцем файла/папки. Системные папки, у которых владелец - система/system, не трогаем также.Igor_G писал(а):"Решение проблемы" - ручками разрешил авторизованному пользователю полный доступ к папке. После этого все заработало нормально.
Второй вопрос: Почему? Система и администратор имеют права полного доступа. Я работаю, как админ.
1) поменять параметр dwDesiredAccess на GENERIC_READ (0x80000000L);Igor_G писал(а):Есть идеи?
2) сделать хотя бы простейший анализ хэндла, возвращаемого CreateFile (равно или не равно -1);
3) выставьте все параметры-хэндлы как Signed Pointer-Sized Integer, иначе у вас на 64-битном будет через раз работать или вовсе не будет;
4) все эти функции не обязательно исполнять в UI-потоке, они потокобезопасны.
Кроме того, в чём смысл использования WinAPI для работы с файлами, когда стандартный функционал с успехом делает то же самое, причём внутренне вызывая те же функции WinAPI (CreateFile / Read/WriteFile / CloseHandle)?
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение