No, there is no app dir structure mandated
by POSIX. That is considered an administrative issue outside of the base POSIX
scope, and is generally covered by packaging conventions like DEB and RPM as de
facto standards. I don't think any platform implemented the proposed 1003.1j
standard. Only /., /.., /dev and /tmp are required as fixed root directory
names, per XBD 10. Each vendor can use whatever paths they prefer, besides
those 4, for the symbolic names listed in XBD 8, such as $HOME or $LIB. In an
embedded system a vendor might well put all utilities and shared libraries
directly into / on a ROM and mount /tmp as an alias of a /dev/NVRAMFS device
subdir.
As to mktemp, as long as it only creates files of regular type, or parent
directories of one, there shouldn't be any problem I see with it using /tmp
since ln is required to handle both those types. A platform that adds, as a
contrived example, a "mimo" file type as a scatter/gather superset of fifos
abstraction for persisting iovec_t templates, might need guard code for use of
the complementary mkmimo utility in a script, rather than emulating the
functionality with multiple use or redirects of fifos to a regular file in a cp
pipe or for loop, as the portable option for a gather operation.
On Monday, November 7, 2016 Martijn Dekker <mart...@inlv.org> wrote:
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.
