2.2.5pre1: unlink design flaw
Simo Sorce
idra at samba.org
Thu Jun 13 12:02:03 GMT 2002
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
More information about the samba-technical
mailing list