[Charset ISO-8859-1 unsupported, filtering to ASCII...] > Michael Shapiro wrote: > > From an interface perspective, no rule includes third-party software. > > There is this directory. Any process can dump stuff there if it likes. > > We have no control over that regardless of what rules or documents we > > invent. > > There's nothing to say some application isn't already dumping stuff there. > > I have to disagree. Nothing prevents third party applications from > scribbling all over the file system, but if they do then we consider it > a bug and it's the application vendor's problem when the application > breaks or causes problems for the system. > > In this particular case, if the directory is non-public, it might go > away in the next release of Solaris, or perhaps even in a patch. We > might decide that it should be non-volatile, or that old files should be > automatically deleted after a while, or that it should be wiped when SMF > restarts. If that breaks an application, our official answer would be > "you shouldn't be using undocumented interfaces". > > Almost none of our interface boundaries are truly enforceable. The most > that we can ever do is to say that certain behaviors are supported and > that other behaviors are not supported.
Exactly: that's the point I was making to Peter. We're saying the same thing. Therefore, as per what we've both said, the notion that we achieve something by removing the "svc" from the pathname or creating yet another directory is just an illusion. My entire point here, SMF_TMPDIR aside, is that the simplest approach here is just to better define the convention and description for what is supported and permissible within etc/svc/volatile. e.g. "You can name something with your FMRI as a prefix and put it there." -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
