Messages in this thread | | | Date | Fri, 3 Dec 1999 17:31:51 -0500 (EST) | From | Alexander Viro <> | Subject | Re: Can't hardlink in different dirs. (BUG#826) |
| |
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> 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/
| |