> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >Oh, great. So your reasons should pass for arbitrary filesystem, right?
>
> It's always been so. Sorry if I am been not clear. I was talking about the
> VFS not about lowlevel fs. I don't either know why coda especially
> dislikes hardlinks.
>
> >Let's see: you are not closing any security hole. You are creating
> >gratitious incompatibility with everything and sundry, just because you
> >can't be bothered to learn standard mechanisms (make a directory
> >unavaliable and none of the links there will be cloned). You propose
>
> This works fine for a .gnupg directory but I just don't like to close the
> door completly to be sure that an rm will delete my files. I can take in
> my home directory useful stuff. I just don't like the idea that when I
> delete a file, the same inode could stay allocated somewhere with my
> ownership and the admin may think I moved my file there.
Arrgh.
1. If you want to remove the file contents use cat /dev/null > file_name
2. If work in heterogenuos environment you _can't_ rely on non-standard
link() semantics.
3. unlink() _never_ used to remove file. It removes one of the references
and not every reference sits in filesystem.
4. all nasty effects can be emulated with open(), which is _not_ a thing
you can change.
> >schemes that require root being involved (group creation, for one).
>
> Yes. I think it's a minor issue as you just need root involved also for
> sharing rw some file in a limited workgroup.
And 'rw' is a keyword here. It's not always the case.
-
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/