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

[PATCH] File#open with write flag does not clear existing files. #6

Closed
Narnach opened this issue Sep 15, 2009 · 14 comments
Closed

[PATCH] File#open with write flag does not clear existing files. #6

Narnach opened this issue Sep 15, 2009 · 14 comments

Comments

@Narnach
Copy link

Narnach commented Sep 15, 2009

In regular Ruby, File#open with the 'w' write flag clears the file. FakeFS did not yet do this.
The fix with a test can be found on my topic branch: http://github.com/Narnach/fakefs/tree/file_open_with_write

@qrush
Copy link
Contributor

qrush commented Sep 18, 2009

+1 to this.

@jmhodges
Copy link
Collaborator

The functionality is absolutely needed. I'm not too terribly inclined with this patch.

Checking the mode and clearing the file out if it exists belongs in File#initialize.

You can see this behavior with the normal File class:
irb(main):001:0> Dir['']
=> ["lib", "LICENSE", "pkg", "Rakefile", "README.markdown", "subdir", "test", "tmp"]
irb(main):002:0> File.new('foo', 'w')
=> #File:foo
irb(main):003:0> Dir['
']
=> ["foo", "lib", "LICENSE", "pkg", "Rakefile", "README.markdown", "subdir", "test", "tmp"]

@jmhodges
Copy link
Collaborator

Obviously, what is also not captured in your tests is that the file should be created if it does not exist but the directory above it does.

@jmhodges
Copy link
Collaborator

That last bit is also not captured, iirc. Expected behavior:

irb(main):002:0> File.new('bar/foo', 'w')
Errno::ENOENT: No such file or directory - bar/foo
  from (irb):2:in `initialize'
  from (irb):2:in `new'
  from (irb):2
  from :0

@Narnach
Copy link
Author

Narnach commented Sep 21, 2009

Looks like I'll have to add more tests to check the edge cases.
Clearing the file in File#initialize does make more sense.
I'll look into it today and see if I can improve it on my topic branch.

@jmhodges
Copy link
Collaborator

Cool. I've got some tests here that are failing that I'll push up.

@Narnach
Copy link
Author

Narnach commented Sep 21, 2009

Great. I'll keep an eye out for them. Thanks!

@jmhodges
Copy link
Collaborator

Hm, okay, so these are an okay start.

A bunch of tests will fail if you actually implemented the code for test_File_new_errors_if_directory_above_it_does_not_exist because many tests rely on being able to write directly to /path/to without creating it first.

I'd hack this out more, but I broke some stuff w.r.t. File.open with my current implementation and it is way, way too late for hacking. (I think the initial values of FileSystem.dir_levels and FileSystem.fs need to change but that's just a gut feeling and I've thought that and been wrong before.)

@jmhodges
Copy link
Collaborator

(Oh, and if those values do have to change, pay attention to line 94 in fileutils.rb. Ugh, I hate that I wrote that.)

@Narnach
Copy link
Author

Narnach commented Sep 21, 2009

Thanks for the warning that tests will fail due to the /path/to thing. IRB confirms you get an error, so fakefs should act the same. There's fixing to be done :)

@Narnach
Copy link
Author

Narnach commented Sep 21, 2009

Because File.expand_path is not yet faked, there are 9 tests that break because file path expansion (for directory existence checking) does not operate within the faked FS but still relies on the current working directory outside of FakeFS.

The upside is that the tests you gisted now pass :)

I've pushed the changes (with those 9 failing tests) to my topic branch.

Faking File.expand_path will likely require mucking around in the FileSystem internals as you predicted :)

@smtlaissezfaire
Copy link
Collaborator

Files modes are respected properly in this branch:

http://github.com/smtlaissezfaire/fakefs/tree/file_modes

@Narnach
Copy link
Author

Narnach commented Sep 30, 2009

Those changes look good!

@defunkt
Copy link
Collaborator

defunkt commented Oct 7, 2009

Merged, thanks Scott!

This issue was closed.
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

5 participants