2.2.5pre1: unlink design flaw

[Simo Sorce]

On Thu, 2002-06-13 at 18:07, Urban Widmark wrote:
> 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 ...)

I can't remember just now, but can you rename it while open?
If you can, then you may rename the file on unlink to a very rare name
and then delete oin close().

> 
> 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).

Maybe jeremy (our posix man :-P) can tell us this one.

> 
> 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.

It is what happen just now and make thing not work ;)

> 
> /Urban
-- 
Simo Sorce
----------
Una scelta di liberta': Software Libero.
A choice of freedom: Free Software.
http://www.softwarelibero.it