I ran into this when trying to fix the Phobos unit tests and have reduced it down to this test file:

import std.stdio, std.file;

void main() {
    auto f = File("test.txt", "w");
    //f.close();
    std.file.remove("test.txt");
}

This compiles and runs fine on linux and the autotester shows that it works on all the tested Posix platforms, but it fails on Windows with

std.file.FileException@std\file.d(433): test.txt: The process cannot access the file because it is being used by another process.

Uncommenting the f.close() gets it to work fine on all supported platforms, no doubt it has to do with the different OS APIs that are being called.

This seems like inconsistent behavior: should I file a bug?

On Saturday, 5 July 2014 at 20:23:03 UTC, Joakim wrote:
> This seems like inconsistent behavior: should I file a bug?

This is because the operating systems do it differently; I think D is doing the right thing by being a pretty thin wrapper around that functionality.

If anything, I'd just say deleting an open file may not be permitted in the docs, implying that the user should always close it themselves before deleting it.

On windows files are traditionally opened without delete sharing, such files can't be deleted until closed, because all sharing options are always honored.

See if stdio allows you to specify delete sharing when opening the file.

On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote:
> See if stdio allows you to specify delete sharing when opening the file.

I don't know what delete sharing is exactly, but the File constructor simply calls fopen and I don't see any option for the Windows fopen that seems to do it:

http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx

On Mon, 07 Jul 2014 12:17:34 +0100, Joakim <dlang@joakim.airpost.net> wrote:

> On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote:
>> See if stdio allows you to specify delete sharing when opening the file.
>
> I don't know what delete sharing is exactly, but the File constructor simply calls fopen and I don't see any option for the Windows fopen that seems to do it:
>
> http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx

The fopen variant that allows you to specify sharing is:
http://msdn.microsoft.com/en-us/library/8f30b0db.aspx

But it does not mention delete sharing there.

CreateFile allows sharing to be specified for delete however:
http://msdn.microsoft.com/en-gb/library/windows/desktop/aa363858(v=vs.85).aspx

So... you could:
 - Call CreateFile giving you a "handle"
 - Call _open_osfhandle to get a "file descriptor"
 - Call _fdopen on the file descriptor to get a FILE* for it

But!  I agree with Adam, leave it as a thin wrapper.  Being a windows programmer by trade I would expect the remove to fail, I would not expect all my files to be opened with delete sharing enabled by default.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Monday, 7 July 2014 at 11:17:35 UTC, Joakim wrote:
> On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote:
>> See if stdio allows you to specify delete sharing when opening the file.

In std.stdio, File(name, mode) is forwarded to _wfopen on Windows and to fopen on posix.

On Windows there are many mode flags supported by the _wfopen function (link above):

If you intend to delete the file immediately after closing it, you can use the "D" mode flag when instantiating the File struct.

-or-

You can write your own wrapper around CreateFile/Ex WinAPI function and use FILE_SHARE_DELETE for dwSharingMode; now you can safely delete the file without closing it even from another process.

It can be also a bad user experience, when delete succeeds only pertially and doesn't free the disk space. Delete-on-close flag should be better in this regard.

On Monday, 7 July 2014 at 12:00:48 UTC, Regan Heath wrote:
> But!  I agree with Adam, leave it as a thin wrapper.  Being a windows programmer by trade I would expect the remove to fail, I would not expect all my files to be opened with delete sharing enabled by default.
>
> R

And I believe behavior is still different. In Linux an open file can be accessed even after a delete operation (unlink). But in Windows is that possible?

On Mon, 07 Jul 2014 15:18:51 +0100, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:

> On Monday, 7 July 2014 at 12:00:48 UTC, Regan Heath wrote:
>> But!  I agree with Adam, leave it as a thin wrapper.  Being a windows programmer by trade I would expect the remove to fail, I would not expect all my files to be opened with delete sharing enabled by default.
>>
>> R
>
> And I believe behavior is still different. In Linux an open file can be accessed even after a delete operation (unlink). But in Windows is that possible?

Not sure, I've never done this.  It's just not something you would typically want/try to do on windows.

If I had to guess, I would say it would still be possible to access the file.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/