-
Notifications
You must be signed in to change notification settings - Fork 92
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
Fake Filesystem Never Empty. There Is Always Folder '/var/folders' on MacOS #329
Comments
Test Further, I searched for "var" and "folders" in the source code and found nothing unusual. Could you please provide code that demonstrates the problem? Thank you. |
That is due to the fact that the temp directory is now always created in I still think that this is more expected behavior than a bug, but you are right of course, that it breaks tests relying on the old behavior. I can think of 2 solutions, both not ideal: add some function in What do you think? And thanks for the fast report BTW, with 3.3 only just released! |
Aha. |
Thanks @mrbean-bremen. I think that you are right. I had written additional comments on this issue (providing an example and some outputs). However, after rereading your answer (and better understanding it), I have deleted those comments. Your answer fully explains the issue in my opinion. I cannot say that this (new) expected behaviour is the best one for a package mocking the filesystem. I rather prefer a mock that only creates those files and folders that are commanded to do. I understand that there are some trade-offs and some implementation decisions that, of course, I am not able to catch as a seasonal programmer. So it is fine. I will refactor my tests to fulfil the new behaviour. Thanks you and @jmcgeheeiv for this nice and useful package. |
I had a look at your results, and I have no idea, where these files come from - this seems to be a location where some caches are stored under MacOS (not the temp directory, actually), and someone must be writing them after |
I have not thought about that. You are right: the filesystem can be written by other modules as well. Nobody should expect that a fake filesystem is still empty after a while because of that. However, in my tests, I usually check that the filesystem is empty just after "creating" the fake filesystem or immediately after deleting all files. So I think that the problem that you mentioned does not apply here, in my tests. Maybe I am wrong about that assumption. On the other hand, I have made the "breakpoint test". The "results" are:
Does this provide useful information to you? Should I perform any additional debugging to get more data? |
Ok, thank you - I wasn't aware that the temp folder location under MacOS is that cryptic (certainly hasn't been this way the time I have worked with it). |
I really do not know so much about /var folder on MacOs. I have found this article: “What is "/var/folders"?” by Magnusviri with some useful details. On the other matter, about the way I use pyfakefs, well... I have coded a home-made library for my own use in several personal projects. Maybe not the best approach, but has worked for me for ages. As well as in many projects around, this library has its own history and its own sins. Checking that pyfakefs was "running" comes from the developing process. At first, I could not manage to make the package work. So I checked that all things were in place. That was long time a ago, before fake_pathlib was implemented and I had to crafted my own mock based on pyfakefs. The feature is still there, in my home-made library, and I found it very useful on my projects. For instance, in this particular case, I use it to check that pyfakefs is working since the /var folders were duplicated in fake and real filesystem. Call it: amateur's insecurity. The library "subclasses" pyfakefs provides additional services and that the reason behind some decisions. For example, checking if the filesystem is empty or not was very useful for subtests. I can "re-start" the filesystem just by deleting all contents and checking if it is empty to assert that everything is fine. At the beginning, I had many inconveniences because of side-effects and checking that the fake filesystem is empty killed all troubles. And so on... As I said, there would be better approaches for sure. Thanks a lot. |
Sorry for resurrecting this issue. I have made some further investigation and I would like to propose some minor changes in the package. First of all, I would like to say that an initial empty fake filesystem is a desired feature for me. So I have tried to revert the actual behaviour to previous one in versions above 3.3. If you consider that this is not a desirable feature, this patch is worthless. My proposal is to delay the creation of the fake temporary directory until it is actually requested. To achieve this, I propose to stub the The stub method The proposed alternative passes the tests of I have made modifications in Both files can be seen at https://gist.github.com/Quibi/05ba9afeb94994123dcfd0bb1e7bbb1f. Changes can be searched by '# HACK' for convenience. In my opinion, the advantages of this approach are:
The disadvantages I can imagine are:
Thank you. |
That sounds reasonable to me. I currently don't have a working PC at home (my hard disk finally died today), so I can't check this very well - but you may just create a pull request and we can go from there. It will take me a few days to get back to that, so take your time ;) |
Ouhh. Hard drives... Sorry about that. My first pull request. It will be a great new experience... |
Before pyfakefs 3.3 (3.2 and above), it is possible to check that the fake filesystem is empty and only has the root directory /. A simple scandir() was enough.
However, since version 3.3 the fake filesystem is not really empty any more. There is always a '/var/folders' directory. Why?
I think that a best solution —the ideal one, I must say— will be that the fake filesystem is really empty, except for root directory. Any file or folder must exist only if you create it. That was the behaviour of pyfakefs till 3.3.
In my case, it causes a lot of errors in my tests. scandir, ListDir, glob, etc. does not returns expected results any more...
Pyfakefs 3.3
Python 3.6.3
MacOs 10.6.2
Thanks a lot
The text was updated successfully, but these errors were encountered: