[erlang-patches] [PATCH] Use share flags for all file operations on Windows

[Filipe David Manana]

Hello,

Can you please refetch?

https://github.com/fdmanana/otp/compare/master...windows_file_share_delete.patch
https://github.com/fdmanana/otp/compare/master...windows_file_share_delete

git fetch git://github.com/fdmanana/otp.git windows_file_share_delete

thank you

On Wed, Oct 24, 2012 at 1:09 PM, Filipe David Manana <fdmanana@REDACTED> wrote:
> On Wed, Oct 24, 2012 at 10:06 AM, Henrik Nord <henrik@REDACTED> wrote:
>> Hi
>>
>> I have added your patch to 'master-pu'.
>
> Thanks Henrik.
>
>>
>> If you are able to reproduce this we would love tests for it. We do however
>> understand if you are not able to reproduce it consistently as it may be
>> dependent on timings and whatnot.
>
> Yes, it's very hard to reproduce it consistently. Basically what I
> encountered was
> that if an Erlang process is "in the middle of" a filelib:file_size/1
> (indirectly uses
> efile_fileinfo C function) call (after it opened the file, with share
> flags set to 0,
> and before it closes the file), other processes attempting to delete, rename or
> even open the file for read only mode, fail with eacces error.
>
> I noticed then that passing all the share flags to the CreateFileW
> call in efile_fileinfo
> was missing, as well as in a few other places other than efile_openfile.
>
>>
>> However, there is a vague feeling that this may have been tried before, and
>> strange errors with "ghost" files that did not exist, but could not be
>> created as the names where taken.
>
> Yep, I think what you're mentioning relates to what is described in
> these 2 pages:
>
> http://social.msdn.microsoft.com/Forums/nl-BE/vcgeneral/thread/54bef96f-3ca1-4dd7-a621-da2fa8d8b35b
> (reply from Friday, October 28, 2011 12:39 PM)
>
> http://stackoverflow.com/questions/3764072/c-win32-how-to-wait-for-a-pending-delete-to-complete
>
> Seems the solution is to rename a file and then delete it. However
> without FILE_SHARE_DELETE, the rename
> operation fails (if the file is already open without share delete
> flag), as I experienced and is mentioned in Microsoft's
> documentation for FILE_SHARE_DELETE:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx
>
> It fails with ERROR_SHARING_VIOLATION, and then the win_efile module
> translates it to EACCES.
> Therefore I think this patch helps on that, but ultimately, due to
> Windows specific file handling, the
> rename + delete seems to be a common practice.
>
> best regards,
>
>>
>>
>>
>>
>> On 10/23/2012 07:56 PM, Filipe David Manana wrote:
>>>
>>>
>>> https://github.com/fdmanana/otp/compare/maint...windows_file_share_delete.patch
>>> https://github.com/fdmanana/otp/compare/maint...windows_file_share_delete
>>>
>>> git fetch git://github.com/fdmanana/otp.git windows_file_share_delete
>>>
>>>
>>
>> --
>> /Henrik Nord Erlang/OTP
>>
>
>
>
> --
> Filipe David Manana,
>
> "Reasonable men adapt themselves to the world.
>  Unreasonable men adapt the world to themselves.
>  That's why all progress depends on unreasonable men."



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."