several issues with pyinstaller on Windows 10

[Eryk Sun]

On 11/18/21, Ulli Horlacher <framstag at rus.uni-stuttgart.de> wrote:
>
> P:\W10\dist>argv a b
> The process cannot access the file because it is being used by another
> process.

Try searching for open handles for "argv.exe" using Sysinternals
Process Explorer [1]. Terminate the offending process.

Since you're inexperienced with Windows, here's a brief explanation of
ERROR_SHARING_VIOLATION (32).

File objects that are opened for filesystem files have a
read-write-delete sharing mode if the open requests any
read-write-delete data access, but not if the open only has metadata
access (e.g. timestamps, ID, attributes, extended attributes,
security). Note that delete access includes the right to rename a
file.

The share mode flags and associated data access rights are as follows:

    FILE_SHARE_READ
        - FILE_READ_DATA | FILE_EXECUTE
    FILE_SHARE_WRITE
        - FILE_WRITE_DATA | FILE_APPEND_DATA
    FILE_SHARE_DELETE
        - DELETE

For example, if an existing open for a file has any data access and
doesn't share read access, then trying to open the file with execute
access will fail as a sharing violation. The security context of the
open request doesn't matter. For example, SYSTEM and administrators
aren't privileged to bypass the sharing mode. It can only be bypassed
from the kernel.

Unfortunately the system error message for ERROR_SHARING_VIOLATION is
misleading. The sharing mode has nothing to do with processes. It's
strictly a function of the File objects that are opened for the file.

Python's open() and os.open() functions share read and write access,
but they do not share delete access. For example, overlapping calls to
open('spam.txt', 'w') are allowed. For os.stat(), the share mode of
existing opens doesn't matter because it opens the file with metadata
access only.

Sharing data access can get messy. Each open has its own file pointer
in the associated OS file object. For example, say an open writes 10
bytes and flushes the buffer. Then a second open(..., 'w') call
overwrites the file, truncating it to 0 bytes. When the original open
writes to the file again, the OS will back fill the file with 10 null
bytes.

Windows also provides byte-range shared and exclusive locking that can
exceed the current size of the file. A byte-range lock doesn't prevent
opening the file with read, write, or delete access, and it doesn't
prevent deleting the file. It causes write or read-write operations on
the range to fail with ERROR_LOCK_VIOLATION (33).

> win32ctypes.pywin32.pywintypes.error: (110, 'EndUpdateResourceW',
> 'The system cannot open the device or file specified.')

This is likely due to a sharing violation. EndUpdateResourceW() [2]
requires exclusive access to the target file. If its internal open
fails for any reason, it maps all errors to this generic
ERROR_OPEN_FAILED (110) error code.

---
[1] https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
[2] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-endupdateresourcew