To be clear, having stat() return an error is not "breaking UNIX" (re
https://bazaar.launchpad.net/~mirabilos/mksh/MAIN/revision/2874). UNIX,
as defined by IEEE Std 1003.1-2017, says:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/stat.html
An implementation that provides additional
I don’t consider it a bug.
If you break stat(2) in your system, expect follow-up breakage, as per
the GIGO principle.
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
Since the concern raised is about portability and buggy implementations,
another strategy which addresses "test" returning inaccurate information
is to conditionally use access(F_OK) only on platforms where it is known
to be reliable. One way (but not the only way) is to use ifdefs, eg.
#ifdef
My system, the Android operating system, uses SELinux to disallow stat()
for a large number of files and directories. This prevents side channel
leakage between various untrustworthy processes, helping preserve user
privacy and preserve the confidentiality of the system. For good reason,
the
If you insist on stat(), then it should be fairly straight forward to
check errno.
File exists if stat() returns success, *or* if stat() returns failure
and errno != ENOENT.
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
On unix. test whether a file exists is done using stat. access is not
portable and buggy on many platforms.
Honestly, write your security policies to not block stat. I’m not even
going to bother with this one.
** Changed in: mksh
Importance: Undecided => Wishlist
** Changed in: mksh
