On Mon, 27 Feb 2012 12:25:28 -0500 (EST) "Matt W. Benjamin" <[email protected]> wrote:
> I think you guys have established that it's mostly harmless for the > file to continue to exist at the fileserver, but that seems to ignore > the client semantics altogether. Like, if a client is going to hoard > the file in response to the callback, it must be able to do everything > that the protocol specifies to enable that. That seems to involve > keeping its registration, or rather getting a new one. So new clients > can get a registration in the delete window? Then when it's really > gone, they'll get another break callback? When it's really gone, nobody gets anything. The file only goes away when there are no active callback promises for X minutes, so the fileserver hasn't promised to anyone that it will notify them of anything. That part of it doesn't change anything wrt fs<->client semantics. > As Simon points out, without improving the callback interface to > clarify the state of 'deleting' files, clients trying to actually to > use the delete window regularly would degrade the fileserver. Yes, of course. If someone holds open a file on some system and you try to delete it, the file will stay around forever as long as that reference is kept on that client; that's the idea :) If you just mean there's no way for a client to say "really delete this file, I don't care if someone else is using it", then yeah, there's no way to do that without updating the protocol. That's what I was trying to say with the concerns about space usage and confidentiality or whatever. I don't know how critical it is for various people, but it is a problem, sure; as far as I'm aware, it is the only problem with such an approach. That issue can seem a bit... less important for the general case to me, since I don't even know what the userspace application-level interface looks like to "really delete" a file beyond an afs-specific pioctl. You don't have this ability even for local filesystems, if you're an unprivileged user trying to delete a file held open by root. Anything concerned with the file being recovered I thought would usually try to "shred" the file by overwriting it with stuff anyway, which still works here. And anything concerned with getting the space back... other filesystems have the same "problem" with no workaround. I'm not objecting that such functionality be added to the protocol; I'm just saying, even in the meantime with the current wire protocol this seems solvable, practically speaking. I'm not going to work on it, but if someone really cares... it seems to me like the described strategy would work. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
