# Venv not function properly in macOS within an exFAT disk

**URL:** <https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145>\
**Category:** Python Help\
**Tags:** packaging-help\
**Created:** [April 24, 2023, 9:32am UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145 "2023-04-24T09:32:30Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![lincw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/lincw/32/12218_2.png) [@lincw](https://discuss.python.org/u/lincw)\
**Post date:** [April 24, 2023, 9:32am UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/1 "2023-04-24T09:32:30Z")

</div>

# TLDR

macOS creates `._*` files for every file in certain file systems like exFAT. As a result, when creating a virtual environment in exFAT, a `._*.pth` file is generated, which contains binary-encoded content that prevents Python from functioning properly.

# Computer information

macOS version: Ventura 13.2.1  
Mac model: Mac mini 2023 with m2  
Python version: 3.11.3

# Issue

After attempting to create a virtual environment by running `python3 -m venv venv` on an external exFAT-formatted disk, I executed the command `pip install -r requirements.txt`. This resulted in the following error:

```python
Fatal Python error: init_import_site: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1178, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1149, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 982, in exec_module
  File "<frozen site>", line 616, in <module>
  File "<frozen site>", line 599, in main
  File "<frozen site>", line 531, in venv
  File "<frozen site>", line 384, in addsitepackages
  File "<frozen site>", line 226, in addsitedir
  File "<frozen site>", line 179, in addpackage
  File "<frozen codecs>", line 322, in decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 37: invalid start byte

```

At this point, the `python` command also produced the same error. However, `python -S` executed successfully.

# Investigation

I ran the `python -vvv` command and extracted the relevant log information below:

```python
Processing global site-packages
Adding directory: '/path/to/project/venv/lib/python3.11/site-packages'
Processing .pth file: '/path/to/project/venv/lib/python3.11/site-packages/._distutils-precedence.pth'
Fatal Python error: init_import_site: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1178, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1149, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 982, in exec_module
  File "<frozen site>", line 616, in <module>
  File "<frozen site>", line 599, in main
  File "<frozen site>", line 531, in venv
  File "<frozen site>", line 384, in addsitepackages
  File "<frozen site>", line 226, in addsitedir
  File "<frozen site>", line 179, in addpackage
  File "<frozen codecs>", line 322, in decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 37: invalid start byte
# destroy site

```

then I inspected the `._distutils-precedence.pth` file:

```python
(venv) ➜ site-packages git:(master) ✗ cat ._distutils-precedence.pth
Mac OS X 2��ATTR��
                                 �
                                  com.apple.provenance$u�@�This resource fork intentionally left blank ��%
(venv) ➜ site-packages git:(master) ✗ file ._distutils-precedence.pth
._distutils-precedence.pth: AppleDouble encoded Macintosh file
(venv) ➜ site-packages git:(master) ✗ file -I ._distutils-precedence.pth
._distutils-precedence.pth: application/octet-stream; charset=binary

```

It is clear that this file was generated by macOS. After researching the issue, I found this explanation: [macos - Why are dot underscore .\_ files created, and how can I avoid them? - Ask Different (stackexchange.com)](https://apple.stackexchange.com/questions/14980/why-are-dot-underscore-files-created-and-how-can-i-avoid-them).  
I deleted the `._distutils-precedence.pth` file, and everything is working correctly now.

# Conclusion

I’m not sure how to permanently resolve this issue. Deleting all `._*` files every time after creating a venv seems to be the best workaround for now. Is there anything I can do or Python can do to prevent from this?

_Perhaps I should consider switching to Linux in the future._

---

<div class="post-metadata">

**Author:** ![codecowboy](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/codecowboy/32/12558_2.png) [@codecowboy](https://discuss.python.org/u/codecowboy)\
**Post date:** [May 21, 2023, 4:30pm UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/2 "2023-05-21T16:30:25Z")

</div>

Just adding a ‘me too!’. I bought a new external drive and formatted it as ExFAT in case I need to use it with Windows & Linux too. I want to store my ML projects there and keep the models in the same place.

This also causes PyCharm problems when creating a virtual environment which is how I encountered it. I’ve logged an issue with JetBrains but expect they’ll say it’s MacOS’s fault.

In the meantime, I’ve used `dot_clean` to remove the files. Hopefully that won’t delete anything used by git?

---

<div class="post-metadata">

**Author:** ![codecowboy](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/codecowboy/32/12558_2.png) [@codecowboy](https://discuss.python.org/u/codecowboy)\
**Post date:** [May 22, 2023, 7:14pm UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/3 "2023-05-22T19:14:06Z")

</div>

You could watch for folder changes using the built-in Automator.app (Look for ‘Folder Changes’ then ‘Run Shell Script’) or the newer Shortcuts app or other suggestions here -

> <https://stackoverflow.com/questions/1515730/is-there-a-command-like-watch-or-inotifywait-on-the-mac>

Shortcuts has options for scripting via js & applescript and also a ‘run shell script’ module

---

<div class="post-metadata">

**Author:** ![ambahk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambahk/32/12784_2.png) [@ambahk](https://discuss.python.org/u/ambahk)\
**Post date:** [June 6, 2023, 6:58am UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/4 "2023-06-06T06:58:35Z")

</div>

+1 on having this problem on an exFAT drive on macos.  
+1 on running `dot_clean .` to solve these problems. It’s a bit iterative since I didn’t setup the Automator as suggested, but it works.

Thanks guys

---

<div class="post-metadata">

**Author:** ![istearley](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/istearley/32/16597_2.png) [@istearley](https://discuss.python.org/u/istearley)\
**Post date:** [December 20, 2023, 8:18pm UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/5 "2023-12-20T20:18:50Z")

</div>

Another workaround is to simply initialize the new Venv on your local machine and then move it onto your exFAT disk before using it.

---

<div class="post-metadata">

**Author:** ![ronaldoussoren](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ronaldoussoren/32/61_2.png) [@ronaldoussoren](https://discuss.python.org/u/ronaldoussoren)\
**Post date:** [December 21, 2023, 9:40am UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/6 "2023-12-21T09:40:42Z")

</div>

@lincw, could you file an issue about this in [the CPython repository](https://github.com/python/cpython/issues/)?

---

<div class="post-metadata">

**Author:** ![ronaldoussoren](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ronaldoussoren/32/61_2.png) [@ronaldoussoren](https://discuss.python.org/u/ronaldoussoren)\
**Post date:** [December 21, 2023, 10:02am UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/7 "2023-12-21T10:02:10Z")

</div>

I’ve reproduced the issue, but this required some manual tweaking on my end:

1. Create a disk image using the exFAT format
2. Create a venv on that
3. Install setup tools
4. Open the “Get Info” panel in the finder for the distutils\_hack.pth file and add a note

The last step forces the creation off metadata that exFAT cannot store natively, and therefore results in the creation of an “.\_” file.

With that file I get the same error as you.

I’ve also filed an issue about this: [Crash when there a ".\_xxx.pth" on macOS · Issue #113356 · python/cpython · GitHub](https://github.com/python/cpython/issues/113356)

---

<div class="post-metadata">

**Author:** ![cameron](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cameron/32/2658_2.png) [@cameron](https://discuss.python.org/u/cameron)\
**Post date:** [December 21, 2023, 11:22pm UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/8 "2023-12-21T23:22:07Z")

</div>

I have the impression that it is the MacOS Finder which makes `._*`  
files. Does your venv have any `._*` files?

---

<div class="post-metadata">

**Author:** ![ronaldoussoren](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ronaldoussoren/32/61_2.png) [@ronaldoussoren](https://discuss.python.org/u/ronaldoussoren)\
**Post date:** [December 22, 2023, 8:07am UTC](https://discuss.python.org/t/venv-not-function-properly-in-macos-within-an-exfat-disk/26145/9 "2023-12-22T08:07:09Z")

</div>

Not just the Finder. These “.\_” files appear when the filesystem doesn’t support metadata that the system wants to write.

One way to reproduce this in the command-line on an exFAT filesystem:

```auto
$ touch hello.txt
$ xattr -w answer 42 hello.txt

```

There’s now a “.\_hello.txt” file as well to contain the extended attribute. You won’t see this file with APFS and HFS+ filesystems because those natively support these.
