If the reason you're checking is so you can do something like if file_exists: open_it()
, it's safer to use a try
around the attempt to open it. Checking and then opening risks the file being deleted or moved or something between when you check and when you try to open it.
If you're not planning to open the file immediately, you can use os.path.isfile
Return True
if path is an existing regular file. This follows symbolic links, so both islink() and isfile() can be true for the same path.
import os.path
os.path.isfile(fname)
if you need to be sure it's a file.
Starting with Python 3.4, the pathlib
module offers an object-oriented approach (backported to pathlib2
in Python 2.7):
from pathlib import Path
my_file = Path("/path/to/file")
if my_file.is_file():
# file exists
To check a directory, do:
if my_file.is_dir():
# directory exists
To check whether a Path
object exists independently of whether is it a file or directory, use exists()
:
if my_file.exists():
# path exists
You can also use resolve(strict=True)
in a try
block:
try:
my_abs_path = my_file.resolve(strict=True)
except FileNotFoundError:
# doesn't exist
else:
# exists
Getting some sort of modification date in a cross-platform way is easy - just call os.path.getmtime(path)
and you'll get the Unix timestamp of when the file at path
was last modified.
Getting file creation dates, on the other hand, is fiddly and platform-dependent, differing even between the three big OSes:
- On Windows, a file's
ctime
(documented at https://msdn.microsoft.com/en-us/library/14h5k7ff.aspx) stores its creation date. You can access this in Python through os.path.getctime()
or the .st_ctime
attribute of the result of a call to os.stat()
. This won't work on Unix, where the ctime
is the last time that the file's attributes or content were changed.
- On Mac, as well as some other Unix-based OSes, you can use the
.st_birthtime
attribute of the result of a call to os.stat()
.
On Linux, this is currently impossible, at least without writing a C extension for Python. Although some file systems commonly used with Linux do store creation dates (for example, ext4
stores them in st_crtime
) , the Linux kernel offers no way of accessing them; in particular, the structs it returns from stat()
calls in C, as of the latest kernel version, don't contain any creation date fields. You can also see that the identifier st_crtime
doesn't currently feature anywhere in the Python source. At least if you're on ext4
, the data is attached to the inodes in the file system, but there's no convenient way of accessing it.
The next-best thing on Linux is to access the file's mtime
, through either os.path.getmtime()
or the .st_mtime
attribute of an os.stat()
result. This will give you the last time the file's content was modified, which may be adequate for some use cases.
Putting this all together, cross-platform code should look something like this...
import os
import platform
def creation_date(path_to_file):
"""
Try to get the date that a file was created, falling back to when it was
last modified if that isn't possible.
See http://stackoverflow.com/a/39501288/1709587 for explanation.
"""
if platform.system() == 'Windows':
return os.path.getctime(path_to_file)
else:
stat = os.stat(path_to_file)
try:
return stat.st_birthtime
except AttributeError:
# We're probably on Linux. No easy way to get creation dates here,
# so we'll settle for when its content was last modified.
return stat.st_mtime
Best Solution
The short answer is no.
The reason, is because the
std::fstream
is not required to use aFILE*
as part of its implementation. So even if you manage to extract file descriptor from thestd::fstream
object and manually build a FILE object, then you will have other problems because you will now have two buffered objects writing to the same file descriptor.The real question is why do you want to convert the
std::fstream
object into aFILE*
?Though I don't recommend it, you could try looking up
funopen()
.Unfortunately, this is not a POSIX API (it's a BSD extension) so its portability is in question. Which is also probably why I can't find anybody that has wrapped a
std::stream
with an object like this.This allows you to build a
FILE
object and specify some functions that will be used to do the actual work. If you write appropriate functions you can get them to read from thestd::fstream
object that actually has the file open.