xfstest 531 and unlink of open file

xfstest 531 and unlink of open file

[Steve French]

Xioli created a fairly simple unlink test failure reproducer loosely
related to xfstest 531 (see
https://bugzilla.kernel.org/show_bug.cgi?id=203271) which unlinks an
open file then tries to create a file with the same name before
closing the first file (which fails over SMB3/SMB3.11 mounts with
STATUS_DELETE_PENDING).

Presumably we could work around this by a "silly-rename" trick.
During delete we set delete on close for the file, then close it but
presumably we could check first if the file is open by another local
process and if so try to rename it?

Ideas?

-- 
Thanks,

Steve

Re: xfstest 531 and unlink of open file

[ronnie sahlberg]

On Mon, Jun 24, 2019 at 1:23 PM Steve French <smfrench@gmail.com> wrote:
>
> Xioli created a fairly simple unlink test failure reproducer loosely
> related to xfstest 531 (see
> https://bugzilla.kernel.org/show_bug.cgi?id=203271) which unlinks an
> open file then tries to create a file with the same name before
> closing the first file (which fails over SMB3/SMB3.11 mounts with
> STATUS_DELETE_PENDING).
>
> Presumably we could work around this by a "silly-rename" trick.
> During delete we set delete on close for the file, then close it but
> presumably we could check first if the file is open by another local
> process and if so try to rename it?
>
> Ideas?

The test is to check "can you unlink and recreate a file while someone
(else) is holding it open?"

I don't think you can rename() a file while other folks have it open :-(
This is likely a place where NTFS is too different from Posix that we
can't get full 100% posix semantics.

>
> --
> Thanks,
>
> Steve

Re: xfstest 531 and unlink of open file

[Jeremy Allison]

On Mon, Jun 24, 2019 at 01:44:53PM +1000, ronnie sahlberg via samba-technical wrote:
> On Mon, Jun 24, 2019 at 1:23 PM Steve French <smfrench@gmail.com> wrote:
> >
> > Xioli created a fairly simple unlink test failure reproducer loosely
> > related to xfstest 531 (see
> > https://bugzilla.kernel.org/show_bug.cgi?id=203271) which unlinks an
> > open file then tries to create a file with the same name before
> > closing the first file (which fails over SMB3/SMB3.11 mounts with
> > STATUS_DELETE_PENDING).
> >
> > Presumably we could work around this by a "silly-rename" trick.
> > During delete we set delete on close for the file, then close it but
> > presumably we could check first if the file is open by another local
> > process and if so try to rename it?
> >
> > Ideas?
> 
> The test is to check "can you unlink and recreate a file while someone
> (else) is holding it open?"
> 
> I don't think you can rename() a file while other folks have it open :-(
> This is likely a place where NTFS is too different from Posix that we
> can't get full 100% posix semantics.

Yeah, this is one of the places you need SMB3+ POSIX extensions
(and even there we fail it if a Windows open exists on the same
handle).