Доступ к этому файлу из системы отсутствует pyinstaller
Обновлено: 07.07.2024
Грустный пример любителя WINa. Чиркани сюда - получилось или нет - интерестно же.
>Грустный пример любителя WINa. Чиркани сюда - получилось или нет - интерестно>>>доступу по номеру группы и владельца. Значит если два юзера с
>же.Почему грустный. Это наоборот приятный пример любителя WINa. В *никсах привязка к доступу по номеру группы и владельца. Значит если два юзера с одним номеров будут, то невозможно отслеживать, а вот в винах идет по SSID, которые не совпадают, разрешения были установлены, потом смена, переустановка и все юзеры с такими же именами получили новые SSID. Вот собственно и все, просто надо было менять владельца у диска, а потом менять разрешения.
>>>одним номеров будут, то невозможно отслеживать, а вот в винах идет
>А ты не знаеш как изменить номер руками, или перенеси диск на
>другой комп, и там и там есть юзер руут и т.д.
>и т.п.
Появился у меня такой жизненный вопрос:- А нафига?
Зачем менять uid руками? Что переносить на диске? Пользователь root имеет идентификатор 0:0 (uid:group), если не ошибаюсь, в любом unix'e. И все же я отвечал на первое утверждение (см. выше), что разные пользователи имеют разные uid'ы.
>Зачем менять uid руками? Что переносить на диске? Пользователь root имеет идентификатор>>Зачем менять uid руками? Что переносить на диске? Пользователь root имеет идентификатор
>0:0 (uid:group), если не ошибаюсь, в любом unix'e. И все же
>я отвечал на первое утверждение (см. выше), что разные пользователи имеют
>разные uid'ы.Хе! А ты не будешт менять. ТЕБЕ поменяют! :)))
>>0:0 (uid:group), если не ошибаюсь, в любом unix'e. И все же
>>я отвечал на первое утверждение (см. выше), что разные пользователи имеют
>>разные uid'ы.
>
>Хе! А ты не будешт менять. ТЕБЕ поменяют! :)))
Глупости! Пользователей с одинаковыми uid в системе быть не должно (и если админ не лох то их и не будет). Для привелегий достаточно иметь gid как у рута, а uid менять это ИМХО плохой тон.
И вообще-то нестоит сравнивать мастдай и юних - разные весовые категории.
>>>Зачем менять uid руками? Что переносить на диске? Пользователь root имеет идентификатор
>>>0:0 (uid:group), если не ошибаюсь, в любом unix'e. И все же
>>>я отвечал на первое утверждение (см. выше), что разные пользователи имеют
>>>разные uid'ы.
>>
>>Хе! А ты не будешт менять. ТЕБЕ поменяют! :)))
>
>Глупости! Пользователей с одинаковыми uid в системе быть не должно (и если
>админ не лох то их и не будет). Для привелегий достаточно
>иметь gid как у рута, а uid менять это ИМХО плохой
>тон.
>И вообще-то нестоит сравнивать мастдай и юних - разные весовые категории.Вот имено, а то не туда куда-то пошла ветка.
>Главное не суетись.
>1) В свойствах ДИСКА смени владельца на группу Администраторы
>2) Меняй разрешения (Администраторы + систем = все, пользователи и другие по
>своему усмотрению)Как писалось выше - все это уже было.
Когда устанавливаешь нового владельца или новые разрешения через
родительские папки (вплоть до самого корня диска) - это применяется
только для нормальных файлов. В тех же, у которых пропала вкладка
"Безопасность" она так и не появляется, при этом при распостранении
наследуемых разрешений никаких ошибок не вываливается, эти файлы
просто пропускаются.Есть у кого ещё какие мысли?
Сначала я скачал сам модуль.
C:\Users\User\Desktop\testing (Python)>pip install pyinstaller
Requirement already satisfied: pyinstaller in c:\users\user\appdata\local\packages\pythonsoftwarefoundation.python.3.9_qbz5n2kfra8p0\localcache\local-packages\python39\site-packages (4.2)
Requirement already satisfied: altgraph in c:\users\user\appdata\local\packages\pythonsoftwarefoundation.python.3.9_qbz5n2kfra8p0\localcache\local-packages\python39\site-packages (from pyinstaller) (0.17)
Requirement already satisfied: pefile>=2017.8.1 in c:\users\user\appdata\local\packages\pythonsoftwarefoundation.python.3.9_qbz5n2kfra8p0\localcache\local-packages\python39\site-packages (from pyinstaller) (2019.4.18)
Requirement already satisfied: pyinstaller-hooks-contrib>=2020.6 in c:\users\user\appdata\local\packages\pythonsoftwarefoundation.python.3.9_qbz5n2kfra8p0\localcache\local-packages\python39\site-packages (from pyinstaller) (2021.1)
Requirement already satisfied: pywin32-ctypes>=0.2.0 in c:\users\user\appdata\local\packages\pythonsoftwarefoundation.python.3.9_qbz5n2kfra8p0\localcache\local-packages\python39\site-packages (from pyinstaller) (0.2.0)
Requirement already satisfied: setuptools in c:\program files\windowsapps\pythonsoftwarefoundation.python.3.9_3.9.1264.0_x64__qbz5n2kfra8p0\lib\site-packages (from pyinstaller) (49.2.1)
Requirement already satisfied: future in c:\users\user\appdata\local\packages\pythonsoftwarefoundation.python.3.9_qbz5n2kfra8p0\localcache\local-packages\python39\site-packages (from pefile>=2017.8.1->pyinstaller) (0.18.2)
Как видите, у меня он уже установлен.
Мы все знаем, как использовать этот модуль.
C:\Users\User\Desktop\testing (Python)>pyinstaller -F test.py
"pyinstaller" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Но вы в прошлом скриншоте ясно видели как я скачал этот модуль. Почему это происходит?
Изменить 3: я заменил __file__ на sys.argv[0] , когда мне нужно узнать местоположение моего скрипта / исполняемого файла. Это не совсем то же самое, но в моем случае, кажется, работает нормально (по крайней мере, на исполняемой версии . ). Теперь все работает нормально, в режиме одного файла, с использованием функции принятого ответа для доступа к файлам ресурсов!
Изменить 2: как показано в комментариях к принятому ответу, проблема связана с разрешением пути в моем сценарии; Я пытаюсь использовать __file__ , чтобы узнать местоположение скрипта, чтобы я мог получить доступ к его файлам ресурсов. Это не работает после упаковки, так как __file__ будет возвращать имя файла из Python.dll в сценарий, поэтому, как правило, нет пути и только имя файла. Поэтому мне нужно найти другой прием, чтобы получить доступ к файлам ресурсов; Обходной путь на данный момент - переместить текущий каталог в исполняемый путь.
Кстати, это означает, что ConfigParser должен сообщать о проблеме при доступе к файлу, а не о том, что раздел отсутствует.
Я обновлю этот вопрос способом, которым я решил этот вопрос разрешения пути.
У меня проблемы с pyinstaller , и, поскольку я использую его впервые, я уверен, что я сделал что-то не так.
Итак, вот проблема: pyisntaller гладко работает на написанном мной сценарии и генерирует некоторые вещи в папке dist . Хорошо, теперь я хочу выполнить его, чтобы увидеть, все ли прошло хорошо, и вот что я получаю:
Моей первой идеей было отсутствие файла logging.conf , поэтому я добавил его (и некоторые другие файлы ресурсов) в файл p_tool.spec , но это не лучше.
Версия Python: 2.6.6, под WinXP. Я использую pyinstaller , так как он мне понадобится для упаковки файлов для рабочей станции Solaris.
Так у кого-нибудь была эта проблема? Единственная связанная с этим тема - это следующий вопрос: Проблема PyInstaller, очень близко к моей проблеме, но безнадежно она не получила ответа ,
Edit3: подробности о ведении журнала удалены, так как на самом деле не связаны с проблемой.
но не могу опубликовать там, кроме как в качестве ответа, я попытался добавить разрешения и показать папку "WindowsApps", но, похоже, ничего не работает.
Вот что дает мне cmd при запуске pyinstaller
и "Systemet kan inte komma åt filen" означает "система не может получить доступ к файлу"
100 ИНФОРМАЦИЯ: PyInstaller: 3,5 101 ИНФОРМАЦИЯ: Python: 3.7.4 101 ИНФОРМАЦИЯ: Платформа: Windows-10-10.0.18362-SP0 103 INFO: пишет C:\Users\Jonathan\Pictures\shimbot2\gui.spec 106 ИНФОРМАЦИЯ: UPX недоступен. 109 INFO: расширение PYTHONPATH путями ['C:\Users\Jonathan\Pictures', 'C:\Users\Jonathan\Pictures\shimbot2'] 110 INFO: проверка анализа 110 ИНФОРМАЦИЯ: Строительный анализ, потому что Analysis-00.toc не существует 111 ИНФОРМАЦИЯ: Инициализация модуля зависимостей графа. 116 ИНФОРМАЦИЯ: Инициализация модуля перехватывает граф. 119 ИНФОРМАЦИЯ: Анализ base_library.zip. 4140 INFO: запущен анализ Analysis-00.toc Traceback (последний вызов был последним): Файл "C:\Users\Jonathan\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\win32ctypes\pywin32\pywintypes.py", строка 35, в pywin32error Уступать Файл "C:\Users\Jonathan\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\win32ctypes\pywin32\win32api.py", строка 43, в LoadLibraryEx вернуть _dll._LoadLibraryEx (имя_файла, 0, флаги) Файл "C:\Users\Jonathan\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\win32ctypes\core\cffi_dll.py", строка 26, в _LoadLibraryEx имя_функции = 'LoadLibraryEx') Файл "C:\Users\Jonathan\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\win32ctypes\core\cffi_util.py", строка 81, в звоните self._raise_error (имя_функция) Файл "C:\Users\Jonathan\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\win32ctypes\core\cffi_util.py", строка 92, в _raise_error поднять исключение OSError: [WinError1920] Systeme kan inte komma åt filen
Во время обработки вышеуказанного исключения произошло другое исключение:
Читайте также: