Improve handling of st_ino

[pytest-dev]

Improve handling of st_ino

[mrbean-bremen]

I have been thinking about this in connection with the file system space and the newly introduced hard link support. I propose to introduce support for both st_ino and st_dev to cover this:

• add st_ino as proposed
• add a default st_dev (instead of None), set st_dev according to the parent directory on file/directory creation
• under Windows, instead of st_dev the result of splitdrive() shall be used (maybe st_dev can be used internally); not sure yet about automatic creation of a new file system if adding a file on a new drive
• add something like AddRoot() to FakeFilesystem to be able to add a new file system root with a new st_dev, with an optional total_space parameter to set the available space per file system
• adapt the space handling for newly created files accordingly, adapt disk_usage to account for the path parameter
• change shutil.move() to use os.rename() if on the same file system, otherwise copy2, as proposed in point 3 (will work with os.rename if PR #101 is merged)
• adapt os.rename() to throw if on different file systems (seems to be the default on most Unix systems, have to check under Windows)
• please add whatever I forgot

@jmcgeheeiv: If this is ok, I may have a go at this somewhere in the next weeks (after the open PRs are merged, to have a consistent start).
If you are going to make a new pypi release, as you proposed, I think it would be a good time before this is added.

[jmcgeheeiv]

How ambitious and impressive.

We will need to make sure that AddRoot() is properly documented with an example.

In the meantime, I'll get on those other PRs and make a release.

[mrbean-bremen]

Ok, thanks. I won't comment on "ambitious and impressive" :p
I have a question regarding st_ino:
Both CreateFile() and CreateDirectory() have an optional inode argument. What is the use case for these? Will this still be needed, if we automatically give each file/directory a unique inode number? If we allow to set set an arbitrary number, this may clash with an existing number (which generally will just increase for each new object) and I'm not sure how to handle this. I see these possibilities:

• remove the argument and document it in the release notes
• make the argument deprecated and issue a warning if using it
• add a backwards compatibility option to support the argument instead of the automatic assignment
  What do you think?