[GLLUG] Sharing /tmp Among Distros

[Ben Pfaff]

Scott Harrison <harris41 at msu.edu> writes:

> There is no doubt in my mind that you know what you are talking about.
> Yet some of what you wrote reads like a contradiction.  Can you fix this
> (or at least fix my confounded brain)?
>  
> > Unlinking a symlink deletes the symlink, not the file it points
> > to.
> 
> I interpret this as: "unlinking does not delete a file"

If a filename resolves to a symlink, the symlink is deleted, not
the file that it points to.

> > Then the tmp cleaner calls unlink("/tmp/dir/passwd")
> > which the kernel expands to unlink("/etc/passwd"), and boom!
> 
> I interpret this as: "unlinking does delete a file"

The difference here is in where the symlink appears in the
filename.  When the kernel resolves a filename /a/b/c/d/e to a
file, the components are treated differently.  In particular,
symlinks for a, b, c, or d are *always* expanded in resolving a
filename.  But symlinks for the final component, e, may or may
not be expanded, depending on the operation: `open' will normally
expand them, but lots of other operations, including `unlink',
will not.

In my first example, I had /tmp/foo -> /etc/passwd.  In /tmp/foo,
`foo' is the final component, so it is not expanded when
unlink("/tmp/foo") is executed.  The symlink is deleted, not
/etc/passwd.

In my second example, I had /tmp/dir -> /etc.  In
/tmp/dir/passwd, `dir' is not the final component, so it must be
expanded when unlink("/tmp/dir/passwd") is executed, so the
effect is that of unlink("/etc/passwd").

> Soft links, hard links?  What am I missing here in terms of what you wrote?

We're talking about soft links.  Hard links aren't very
interesting from this perspective.
-- 
"Mon peu de succès près des femmes est toujours venu de les trop aimer."
--Jean-Jacques Rousseau