[linux-cifs-client] CIFS client leaving cifs???? files

[Mark Buechler]

Ok, after a bit more research and information from another investigator of
this I've found out that in order for open files to get deleted the client
(cifs fs in this case) needs to set DELETE_ON_CLOSE when opening the file.
This is only available when using also using CIFS_XATTR and CIFS_POSIX and
ea support enabled on the server side. Given I have all of these enabled,
I'm still curious as to why these files are hanging around instead of
getting deleted as they should.

If anyone has any ideas or suggestions I would very much appreciate them.

Thanks, Mark.

On 12/20/06, Mark Buechler <mark.buechler at gmail.com> wrote:
>
> So, I take it this is by design?
>
> - Mark.
>
> On 12/18/06, Jeremy Allison <jra at samba.org> wrote:
> >
> > On Mon, Dec 18, 2006 at 03:24:28PM -0500, Mark Buechler wrote:
> > > I'm running samba v3.0.23c and the latest cifs kernel module on my
> > cifs
> > > client. I'm mounting my samba share on my client with "-o direct". I'm
> >
> > > seeing something odd with regard to unlinking open files. I run
> > MythTV. When
> > > Myth deletes a recording, rather than doing a straight unlink it does
> > the
> > > following:
> > >
> > > 1. Open file
> > > 2. Gradually truncate the file
> > > 3. When the file gets below a certain file size, unlink it
> > > 4. Close file
> > >
> > > This behavior has a side effect of leaving the truncated files hanging
> > > around but renamed as cifs??? files. Ie:
> >
> > Hmmm. Steve - how about using the CIFS UNIX call SMB_SET_FILE_UNIX_BASIC
> > (trans2 call info level 0x200) with a st_nlink count of zero and a
> > file type of UNIX_TYPE_FILE (0) to unlink a file ? That way would
> > work for open files without having to invent a new UNIX_unlink
> > call ? Currently st_nlink of zero is used in a "special" way
> > to do mknod calls so there is precedence for this ?
> >
> > What do you think ?
> >
> > Jeremy.
> >
>
>
-------------- next part --------------
HTML attachment scrubbed and removed