Open ekilmer opened 7 years ago
Here would be a potential pull request with what I would change. https://github.com/angr/simuvex/compare/master...ekilmer:posix-open-check
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.
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.
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
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
Maybe I'm not understanding or grasping the bigger picture here, but should
posix.open
always return a newfd
even if a file of the same name exists?As it is now, if there is no
preferred_fd
number passed to posix.open, thenfd
is assigned an unused number and returned.Would it make more sense to check if the file already exists on line 156?
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 differentfd
s.I see that there is a check if the
name
occurs inself.fs
, which makes it seem like it is not intended to have superfluousfd
s 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!