To last question, yes, but the effects are supposed to be documented so generic guard code that may invoke platform specific pre-ln attempt handling can be written. This is a compromise to disqualifying a system that defines additional file types from being considered conforming at all. In a script this might look like: if [ -e /app/$platform/linkhandler ] ; then { . .../linkhandler } else { do ln directly }; fi
To some extent it's also the operator's responsibility to sandbox use of non-standard file types outside directories the standard says portable applications need access to, such as $TMP, to avoid issues. A platform aware application might create such a file in a $TMP/appsubdir directory but shouldn't link it into /tmp after, iow, but to an ~/app/files type directory instead. That is more a training issue to me, not something the standard can reasonably address or make a requirement. On Sunday, November 6, 2016 Martijn Dekker <mart...@inlv.org> wrote: Op 02-11-16 om 13:32 schreef Martijn Dekker: > If both 'mkdir' and 'ln' operate atomically, there could be a safe > workaround for creating a regular file directly under /tmp. It would > involve creating a (very) temporary directory under /tmp using 'mkdir > -m700', then creating the file inside there, setting the mode, etc. with > no need for atomicity, then attempting to 'ln' that file back to /tmp > until we've got an available name. Do you think this could work? No one replied to poke holes in this, so I went ahead and implemented this workaround in the modernish shell library implementation of 'mktemp'. <https://github.com/modernish/modernish> Just one thing still worries me a bit. Though 'ln' without the -f option is never supposed to overwrite files, the spec also states: | If the last operand specifies an existing file of a type not | specified by the System Interfaces volume of POSIX.1-2008, the | behavior is implementation-defined. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ln.html Does this mean I cannot actually rely on 'ln' not overwriting a file or otherwise behaving unexpectedly? Thanks, - M.