pytest error on (Windows + RAM drive) when using datadir fixture

[abelcheung]

Pytest is reporting OSError with even trivial test case below:

C:\Users\foobar\repo> type tests\test_datadir.py

def test_datadir(shared_datadir):
    assert True

Gist link for error log here.

---

It happens only when following requirements are all met:

1. datadir or shared_datadir is actually used in test case, even only as function argument. Tests not using these fixtures at all would be fine.
2. Windows temp path is using RAM disk, not normal drives attached to physical storage

For second point, above test case would succeed if pytest is instructed to use normal drive as temp, like:

pytest --basetemp=C:\Temp -k test_datadir -s tests\

As extra info, here is my RAM drive setup (if it is useful at all):

C:\Users\foobar\repo> imdisk.exe -l -u 0
Drive letter: M
Image file: \BaseNamedObjects\Global\RamDyne8694d353
Size: 12884901888 bytes (12 GB), Proxy, HDD, Modified.

C:\Users\foobar\repo> echo %TEMP%
M:\Temp

---

The issue pytest-dev/pytest#5826 has symptom very similar to this one, which ultimately points to long time unfixed python bug in Path.resolve(). Comment in Python bug 33016 also has some insight about resolve() being unable to handle Windows filesystem API properly.

While it may not be the responsibility for pytest-datadir to handle such failure, how about some warning ahead. such as in README, for similar user case? Because the bug doesn't manifest unless datadir plugin is installed and used, people may come search here for solution initially. Not to mention the real bug won't go away anytime soon...

[nicoddemus]

Hi @abelcheung,

While it may not be the responsibility for pytest-datadir to handle such failure, how about some warning ahead. such as in README, for similar user case?

👍 from me, a "warning on Windows" section with the explanation you already provided sounds great.

Would you like to contribute that?

[abelcheung]

Sure, why not. I can wrap up a section and submit as PR soon, if everybody think it's fine.

[nicoddemus]

Sounds great!

[abelcheung]

After more investigation, perhaps this issue can be closed as is. The incompatibility is not an isolated issue between python and ramdisk support, but a whole swamp of incompatible software against a specific type of ramdisk.

There are 2 types of ramdisk:

• Direct I/O disk, faster but incompatible with many stuff, even including common Windows software installation
• SCSI emulation disk, slower but better compatibility

imdisk happens to support Direct I/O only, and almost no software attempt to fix issues with such disks. Therefore I switched ramdisk software, and is a happy user now. The issue described here no more manifests.