2.2.5pre1: unlink design flaw

[Urban Widmark]

On 13 Jun 2002, Simo Sorce wrote:

> And samba is not the only application that do this kind of operation,
> the proper fix would be to make smbfs driver able to "hide" a file if it
> is unlilnked but yet open by some process, and then silently unlink it
> when the last process closes it.
> 
> It just involves a per open file counter and some kind of magic on
> directory listing/file opening.

I have thought about this before. It doesn't fix everything, but maybe it
helps for Jochens problem. One problem with hiding is that the file should
remain open on the server:

	fd = open("aa");	Server returns fid 1234
	unlink("aa");		smbfs hides aa from all dir listings etc.
	read(fd, buf, 1);	reads and writes aa
	write(fd, buf, 1);

But if some program then does:

	open("aa", O_CREAT ...)

The server will not create a new file aa because it already exists. So
you'd have to return an error here or get into a mess of having multiple
"shadow" files that would have to be created on the server sometime later.


I have no idea what posix says about open and unlink, but I'm guessing if
it's been unlinked it shouldn't prevent creating a new file (or dir).

Of course the current smbfs behaviour isn't even close to posix(?) anyway,
in the example above the read() will fail because the file is closed in
unlink(). The other simple option is to fail the unlink because the file
is open.

/Urban