Op 07-11-16 om 03:55 schreef Shware Systems: > 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
Thanks for the reply. Where can I find more info about this? Is there a standardised /app directory structure? I don't find it on any actual system I've access to. > 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. That makes sense. Many things would break if /tmp does not operate portably. > 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. Unfortunately, by far the most common use case of 'mktemp' is to create a temporary file in /tmp, so my cross-platform shell implementation of it will have to be able to do that. For the time being, unless anyone has concrete evidence or convincing arguments to the contrary, I will assume that any issues with 'ln' atomicity into /tmp are theoretical. - M.