Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

_add_c_drive() failure when user does not have access to c: #573

Closed
stephenfuqua opened this issue Dec 3, 2020 · 8 comments
Closed

_add_c_drive() failure when user does not have access to c: #573

stephenfuqua opened this issue Dec 3, 2020 · 8 comments

Comments

@stephenfuqua
Copy link

Describe the bug

When using pyfakefs 4.3.0 with pytest, the patcher's setUp function calls _add_c_drive. This works when I execute locally or on my build server when executed manually. It fails, however, when run by the build server using a service account. I think the problem is that the service account does not have access to read the C: drive. Side note: for these tests I actually want to simulate a Linux filesystem. The setUp function is setting up C: before I can intercept the fs object and set the os to Linux.

Final parts of the stack trace:

...\lib\site-packages\pyfakefs\fake_filesystem_unittest.py:727: in setUp
    self.fs._add_c_drive()
...\lib\site-packages\pyfakefs\fake_filesystem.py:1026: in _add_c_drive
    self.root.get_entry('C:') .st_dev = self.last_dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <pyfakefs.fake_filesystem.FakeDirectory object at 0x0000023C9DD61610>
pathname_name = 'C:'

    def get_entry(self, pathname_name):
        """Retrieves the specified child file or directory entry.
    
        Args:
            pathname_name: The basename of the child object to retrieve.
    
        Returns:
            The fake file or directory object.
    
        Raises:
            KeyError: if no child exists by the specified name.
        """
        pathname_name = self._normalized_entryname(pathname_name)
>       return self.contents[to_string(pathname_name)]
E       KeyError: 'C:'

How To Reproduce

  1. Install pytest (6.1.2) and pyfakefs (4.3.0)

  2. Create a simple test like the following:

    import pytest
    
    def describe_will_this_fail():
        @pytest.fixture
        def fixture(fs):
            fs.os = "linux"
    
        def it_should_not_fail(fs, fixture):
            assert 1 == 1
    
  3. Run pytest from an account that does not have access to C:.

Your enviroment

Windows-10-10.0.17763-SP0
Python 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)]
pyfakefs 4.3.0
@stephenfuqua
Copy link
Author

I will try to make time to debug further and see if I can offer a patch. For now I've reverted to an older version.

@mrbean-bremen
Copy link
Member

Thanks - that was a kind of micro-optimization that probably was too fragile. I think I'll just revert that (Windows-specific) optimization, I didn't like it anyway. It will add a millisecond to the test setup under Windows, but I can check later if this can be optimized in a nicer way.

mrbean-bremen added a commit that referenced this issue Dec 3, 2020
- can break tests under some conditions
- see #573
@mrbean-bremen
Copy link
Member

Please check if the current master works for you, and if you need a patch release.

@stephenfuqua
Copy link
Author

Yes, that works. Thank you.

Test process: I created a temporary build configuration in TeamCity so that I could closely replicate the original process. In this configuration wrote a small script that installs pytest and pyfakefs from the canonical sources and runs the sample above. As expected, execution failed. Then I modified the build configuration to clone this repository and install the local clone into the virtual environment. Build configuration now succeeds.

@mrbean-bremen
Copy link
Member

Thanks! I didn't add a regression test, as this was basically a revert, but had to ensure that it works in your use case.
Do you need a patch release with the fix?

@stephenfuqua
Copy link
Author

Patch release would be convenient, but it is not necessary. We can wait until the next one.

@mrbean-bremen
Copy link
Member

Ok, thanks - in this case I will wait if something else comes up, and probably make a patch in a couple of weeks.
Closing this as fixed.

@mrbean-bremen
Copy link
Member

The bugfix release is out now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants