github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 10:58:17 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #5642] issue: windows Functions - [WinError 32] The process cannot access the file because it is being used by another process #14066

New Issue
Closed
opened 2026-04-19 20:33:27 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-04-19 20:33:27 -05:00
Owner
Copy Link

Originally created by @tjbck on GitHub (Sep 23, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/5642

Discussed in https://github.com/open-webui/open-webui/discussions/5606

Originally created by @tjbck on GitHub (Sep 23, 2024). Original GitHub issue: https://github.com/open-webui/open-webui/issues/5642 ### Discussed in https://github.com/open-webui/open-webui/discussions/5606
GiteaMirror added the help wanted label 2026-04-19 20:33:27 -05:00
GiteaMirror commented 2026-04-19 20:33:28 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Sep 23, 2024):

@EtiennePerot Related #5511

<!-- gh-comment-id:2369791641 --> @tjbck commented on GitHub (Sep 23, 2024): @EtiennePerot Related #5511
GiteaMirror commented 2026-04-19 20:33:28 -05:00
Author
Owner
Copy Link

@EtiennePerot commented on GitHub (Sep 24, 2024):

Hmm. It seems like it is complaining that a file is being accessed from multiple processes, but the code specifically closes the temporary file prior to calling exec (by virtue of ending the with block):

6b463164f4/backend/open_webui/apps/webui/utils.py (L87-L97)

I don't have a Windows machine to test this on either, but the Python documentation on tempfile.NamedTemporaryFile helpfully states:

Opening the temporary file again by its name while it is still open works as follows:
On POSIX the file can always be opened again.
On Windows, make sure that at least one of the following conditions are fulfilled:

  • delete is false
  • additional open shares delete access (e.g. by calling os.open() with the flag O_TEMPORARY)
  • delete is true but delete_on_close is false. Note, that in this case the additional opens that do not share delete access (e.g. created via builtin open()) must be closed before exiting the context manager, else the os.unlink() call on context manager exit will fail with a PermissionError.

So I think adding delete_on_close=False should suffice, given that the file is deleted later in the finally block. I can send a PR for that soon.

EDIT: This is incorrect. See comment below.

<!-- gh-comment-id:2369846218 --> @EtiennePerot commented on GitHub (Sep 24, 2024): Hmm. It seems like it is complaining that a file is being accessed from multiple processes, but the code specifically closes the temporary file prior to calling `exec` (by virtue of ending the `with` block): https://github.com/open-webui/open-webui/blob/6b463164f4b129e0ce4bdc9008dd661214fe5eb5/backend/open_webui/apps/webui/utils.py#L87-L97 I don't have a Windows machine to test this on either, but the [Python documentation on `tempfile.NamedTemporaryFile`](https://docs.python.org/3/library/tempfile.html#tempfile.NamedTemporaryFile) helpfully states: > Opening the temporary file again by its name while it is still open works as follows: > On POSIX the file can always be opened again. > On Windows, make sure that at least one of the following conditions are fulfilled: > * `delete` is false > * additional open shares delete access (e.g. by calling [os.open()](https://docs.python.org/3/library/os.html#os.open) with the flag O_TEMPORARY) > * `delete` is true but `delete_on_close` is false. Note, that in this case the additional opens that do not share delete access (e.g. created via builtin [open()](https://docs.python.org/3/library/functions.html#open)) must be closed before exiting the context manager, else the [os.unlink()](https://docs.python.org/3/library/os.html#os.unlink) call on context manager exit will fail with a [PermissionError](https://docs.python.org/3/library/exceptions.html#PermissionError). So I think adding `delete_on_close=False` should suffice, given that the file is deleted later in the `finally` block. I can send a PR for that soon. EDIT: This is incorrect. See comment below.
GiteaMirror commented 2026-04-19 20:33:29 -05:00
Author
Owner
Copy Link

@tcgumus commented on GitHub (Sep 24, 2024):

faced the same problem with the latest build on windows. @EtiennePerot does your solution solves it? I will try it today.

<!-- gh-comment-id:2370298073 --> @tcgumus commented on GitHub (Sep 24, 2024): faced the same problem with the latest build on windows. @EtiennePerot does your solution solves it? I will try it today.
GiteaMirror commented 2026-04-19 20:33:30 -05:00
Author
Owner
Copy Link

@EtiennePerot commented on GitHub (Sep 24, 2024):

No, I was wrong above. NamedTemporaryFile actually keeps an open file handle, and the problem is actually from the os.unlink call later in the function that tries to remove it while the handle is still open. This is OK in POSIX but not in Windows. I just sent #5649 which should fix it by closing the file handle returned by NamedTemporaryFile, which works on either platform.

<!-- gh-comment-id:2370300592 --> @EtiennePerot commented on GitHub (Sep 24, 2024): No, I was wrong above. `NamedTemporaryFile` actually keeps an open file handle, and the problem is actually from the `os.unlink` call later in the function that tries to remove it while the handle is still open. This is OK in POSIX but not in Windows. I just sent #5649 which should fix it by closing the file handle returned by `NamedTemporaryFile`, which works on either platform.
GiteaMirror commented 2026-04-19 20:33:31 -05:00
Author
Owner
Copy Link

@tcgumus commented on GitHub (Sep 24, 2024):

Yes. #5649 solved my problem on windows. thanks @EtiennePerot 👏

<!-- gh-comment-id:2370399222 --> @tcgumus commented on GitHub (Sep 24, 2024): Yes. #5649 solved my problem on windows. thanks @EtiennePerot 👏
GiteaMirror commented 2026-04-19 20:33:31 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Sep 24, 2024):

Thanks everyone!

<!-- gh-comment-id:2370668452 --> @tjbck commented on GitHub (Sep 24, 2024): Thanks everyone!
GiteaMirror commented 2026-04-19 20:33:32 -05:00
Author
Owner
Copy Link

@github-pmj commented on GitHub (Sep 24, 2024):

Just upgraded to 0.3.28 - issue resolved - thanks all for your efforts

<!-- gh-comment-id:2371939618 --> @github-pmj commented on GitHub (Sep 24, 2024): Just upgraded to 0.3.28 - issue resolved - thanks all for your efforts
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label help wanted
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#14066
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?