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

0 byte read does the wrong thing #228

Closed
agroce opened this issue Jun 18, 2017 · 6 comments
Closed

0 byte read does the wrong thing #228

agroce opened this issue Jun 18, 2017 · 6 comments
Labels

Comments

@agroce
Copy link

agroce commented Jun 18, 2017

import pyfakefs.fake_filesystem
import os

fs = pyfakefs.fake_filesystem.FakeFilesystem()
fs.CreateDirectory('/Volumes')
fs.CreateDirectory('/Volumes/ramdisk')
fs.CreateDirectory('/Volumes/ramdisk/test')
os0 = pyfakefs.fake_filesystem.FakeOsModule(fs)

component0 = "h"
path0 = "/Volumes/ramdisk/test"
path1 = path0 + "/" + component0
fd0 = os0.open(path1, os.O_CREAT | os.O_WRONLY | os.O_TRUNC)
bytes0 = 0
result = os0.read(fd0,bytes0)

should throw OSError with errno 9 (bad fd) according to os

(yes, I added reads just now)

@jmcgeheeiv
Copy link
Contributor

This guy's an animal! Keep going, @agroce!

@agroce
Copy link
Author

agroce commented Jun 19, 2017

I'm a lazy professor in the summer, but the random testing tool is indeed an animal. Once it finds something, my job's about three minutes of copy/paste to github. :)

It's running clean on a test regime that omits (of interesting functions in FakeOSModule, e.g. I'm not doing syncs):

  1. rename
  2. symlinks
  3. multiple open file descriptors

since if run with any of those it'll just rediscover the open issues. I expect that #3 is probably hiding a number of fun things once the truncate issues are handled.

I'm also not messing with permissions, since until I get around to dropping this in a virtual machine I can just kill at will, I know from experience that random setting of permission bits in the real file system can turn annoying fast.

@mrbean-bremen
Copy link
Member

As I wrote, the low-level file functions (e.g. os.open, os.read, os.write as opposed to the file functions open, read, write) are very likely incomplete, as they are practically not used in application code. I only added basic support for other modes than O_CREAT for os.open a week ago, so there is definitely more to do, but I may handle these with lower priority.

@agroce
Copy link
Author

agroce commented Jun 19, 2017

Gotcha. I'll leave the simpler and more straightforward ones at least here for examination, then. I haven't built anything to test open/read/write yet, and aimed to fuzz the underlying FS implementation before the sugar on top, but if open/read/write are doing most of their own work I should handle them at some point.

@mrbean-bremen
Copy link
Member

I just understood why the error handling for the low-level functions is incorrect - they are implemented using the high level (fake) functions. This will be a larger rewrite, I leave that for a later time when the temperature is a little down (e.g. compatible with my brain functioning normally).

@mrbean-bremen
Copy link
Member

Fixed with #235.

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

No branches or pull requests

3 participants