[lug] C++, fstream, finding name of open stream

[D. Stimits]

Jonathan Briggs wrote:
> 
> D. Stimits wrote:
> 
> >Does anyone here know if there is a way to extract the file name and
> >path (I need full path) from an ifstream or fstream in general under
> >Linux/g++? I've been looking through the headers for fstream and related
> >files, there doesn't seem to be any direct mechanism for finding the
> >file name and path when given an open fstream (I'm using ifstream). I'm
> >assuming that if there is a way, it is probably system-dependent.
> >
> >D. Stimits, stimits at idcomm.com
> >_______________________________________________
> >Web Page:  http://lug.boulder.co.us
> >Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> Ask yourself if you really need to do this.  If you do for some reason,
> keep in mind that there is no guarantee the file you have open still has
> the same name!  The file may have been renamed or deleted while you are
> using it.  Your file handle is still valid, but the filename may be
> different or completely gone.
> 
> Forgetting this has been a cause of several security holes in the past.
> 
> If you still need the filename, I'd recommend using a completely
> portable solution.  Derive your own class from ifstream.  Write new
> constructor and open functions that saves the filename into a member
> variable and write an access function to get the value back.
> 
> I just finished looking at the GCC 3.0 libio source.  It doesn't look
> like ifstream stores the filename anywhere.  It is only used to open the
> file.  After that, it's gone.
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

I'm interested in doing some file validation as to permissions, and
whether a request to set a file source identity is the same file that is
already open. It is only being read, not written, so it isn't a security
problem to change names. It is possible the file path will be set up and
left open, then accessed later; it is also possible that the file spec
will be changed, in which case I want to either (a) determine that this
is the same file and do nothing except return success, or (b) close the
different file and set the new spec. But it seems like maybe I should be
validating a node instead of a stream. Somehow I would like to associate
a node with a stream. If I merely save information on file path from the
original opening, I would not know by name comparison if the file was
renamed; comparing both inode and name together would do the trick.
But...assuming a stream is being passed around, it would be easier and
more eloquent to extract the inode specs from the stream than it would
be to memorize it and pass the data everytime I pass the stream. On the
other hand, it isn't critical to me, it is just a convenience if I can
query a stream for what it is looking at...that means anything passing
it does not have to be aware of my validating procedure, I can just
compare ad hoc streams. Somehow it seems a bit silly though that a file
stream doesn't have a means of uniquely identifying itself the way a
file descriptor would (I can do an fstat on a descriptor...I'd love an
overloaded fstat() that accepted an fstream in place of a descriptor). I
can live without it, but life would be simpler with it.

D. Stimits, stimits at idcomm.com