Re: fopen - file and directories ??
On Oct 6, 8:09 am, Paavo Helde <pa...@nospam.please.ee> wrote:
"fdm" <f...@gk.com> kirjutas:
I have modfied this piece that the author claims to be
"compatible with more that windows":
[...]
to this:
if ( !access( file.c_str(), 0 ) == 0 ) {
[...]
But when I run it on linux it cannot find io.h. So as you
point out it
Right, on Linux/POSIX it is elsewhere, see man access
I'm not even sure that access is standard Windows. Although
Windows has wrappers for a lot of the Posix functions, there are
often subtle differences (Windows is not Posix), and I generally
prefer using the native functions. In this case: access is
often just a wrapper around stat in Unix implementations as
well, and I'll generally just use stat or GetFileAttributes
directly.
Note that at least under Posix (and probably under Unix as
well), this may fail even if the file or directory exists, if
for example you don't have adequate access rights to some lower
directory in the path. Which means that you'll probably have to
look at the cause of failure (errno, GetLastError) in case of
failure.
A more nasty difference is that in order to work correctly
with filenames containing all possible characters (umlauts,
hieroglyphs, etc), your code has to support filenames encoded
as UTF-8 in Linux (this is the common case) and as UTF-16 on
Windows, and you have to use different string type and a
different function (_waccess()) on Windows. So you just can't
call access() and be portable. A proper solution is that you
decide what internal encoding you are using in your program,
then declare your own internal function like
int my_access(const std::string& filename_utf8, int mode);
then implement this function differently in two separate
source files, with encoding conversions etc., one of which is
compiled only in Windows and the other only in Linux. The
Windows source file includes <io.h>, the Linux source file
includes some other header. The rest of the program just uses
my_access() instead of access().
You're right, of course, but you're opening up a real can of
worms. First of all, at least under Posix/Linux, the filename
isn't necessarily UTF-8; the system makes no requirements
concerning the filename except that the individual components in
the path do not contain a character encoded with 0x00 or 0x2F
('/' in ASCII, ISO 8859 and UTF-8); this does eliminate
encodings like UTF-16, but ISO 8859-1 is quite common, as is
UTF-8. And since the only place the encoding makes a difference
is when displaying the file names, it's quite possible to use
different encodings for different files, even in the same
directory. (Sort of makes the output of ls a bit wierd to look
at, but the system doesn't care.) Under Windows, of course, the
native encoding is (so I've heard) UTF-16LE, but when passed a
name encoded in a char[], it assumes the current code page to do
the conversion. It's restrictions are also expressed in the
form of "any character except"..., which leaves a lot open. And
of course, remotely mounted files (both under Unix and under
Windows) may introduce other restrictions. (See
http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
for a discussion of some of the issues under Windows.)
Yes, this is a lot of work to do, as this concerns all
filesystem related functions. I think boost::filesystem
library should solve such issues, but I have not used it
myself.
I doubt that it addresses the encoding issues, since there is
basically no general solution possible.
--
James Kanze