> Alexander Viro <viro@math.psu.edu> writes:
>
> |> On 15 Feb 1999, Andreas Schwab wrote:
> |>
> |> > NFS or local disk? That certainly makes a difference. The kernel in
> |> > general does not care, but the filesystem may.
> |>
> |> Andreas, I had tested it only on 5.6 and there it gives the same result on
> |> (a) NFS, (b) tmpfs, (c) local disk (UFS).
>
> I have now found the difference: the home directory, where i tested it, is
> mounted via lofs. I can confirm that rmdir fails as documented on tmpfs
> (/tmp) and ufs (/var/tmp).
>
> But it looks still strange to treat the pwd of the current process in such
> a special way. That does not make any sense.
... and SUS2 doesn't mention names ending with "." as a possible reason
for failure. Weird. Anyway, I think that (a) no matter which policy we
will take it should be done in VFS (*not* in filesystems - see your
example with lofs) and (b) we may need a generic mechanism for dealing
with such stuff.
What about adding a boolean vector to the struct task and adding a
new syscall:
int POSIX_lossage(struct lossageset_t *new, struct lossageset_t *old);
with semantics a-la sigprocmask(2) (and maybe some way to determine
whether the thing will be inherited over exec() or not)? Maybe it would be
reasonable to make it available via /proc/<pid>/current_lossage too.
On the kernel side it would mean adding int losing(int kind_of_lossage);
modelled after capable() and protecting the losing checks in VFS with
if (losing(LOSSAGE_FOO)) {
/* do losing things */
}
s/lossage/features/ if you want political correctness. I really think
that such mechanism might be useful. Comments?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/