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