Should posix.open always create a new file descriptor?

[ekilmer]

Maybe I'm not understanding or grasping the bigger picture here, but should posix.open always return a new fd even if a file of the same name exists?

As it is now, if there is no preferred_fd number passed to posix.open, then fd is assigned an unused number and returned.

Would it make more sense to check if the file already exists on line 156?

else:
    tmp = self.filename_to_fd(name)
    if tmp:
        fd = tmp
    else:
        for fd_ in xrange(0, 8192):
            ...

Truth be told, I haven't tested this on anything other than my use-cases, but from what I've seen, the existing logic seems to be polluting the self.files dictionary with copies of my file, all with different fds.

I see that there is a check if the name occurs in self.fs, which makes it seem like it is not intended to have superfluous fds pointing to the same file, but I'm still becoming familiar with the backend, so I could be misunderstanding.

Any insight would be appreciated!
Thank you!

[ekilmer]

Here would be a potential pull request with what I would change. master...ekilmer:posix-open-check

[zardus]

Is your usecase the reading and writing of a file from the same path? This is something that's (surprisingly) not possible with the current approach -- the actual file contents exist in the SimFile, and a SimFile is really a sort of "SimFileDescriptor", with a position and so forth.

The right thing to do is to move the content into whatever is representing the filesystem itself, and make SimFile (or SimFD or whatnot) a reference to that, with a seek position tacked on.

[ekilmer]

Hmmm okay. Thanks for the tip. Let me look into it more and try to create a simple example over the weekend, which should make it clearer as to what I'm doing right or wrong.

[ekilmer]

Finally got around back to this...

I am trying to open the same file twice in a run (open, close, open, close) as seen in the test program below. In order to do this, I tried following @zardus advice. I don't think I entirely understand what the posix.fs dictionary is used for. I feel like posix.fs should hold the contents of a file like {path: SimFile} and that posix.files should be {fd_int: metadata_obj} where the metadata_obj can have the file's path, permissions, read position, etc.

It could be visualized similar to this, but combine the file descriptor table and file table.

Source: https://en.wikipedia.org/wiki/File_descriptor

[rhelmot]

hi, I just took an os class and can comment on this with some degree of authority, yes the model you described is a good representation of how to do things. The current system was definitely designed with the intent of being as simple as possible and not following the established OS conventions whatsoever