MemoryMappedFile possible problem with shared access modes

HANDLE h = CreateFile (file.getFullPathName().toWideCharPointer(), accessMode,
                       exclusive ? 0 : (FILE_SHARE_READ | (mode == readWrite ? FILE_SHARE_WRITE : 0)), 0,
                       createType, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, 0);

I can’t read a file I’m writing to with MemoryMappedAudioFormatReader but I can with AudioFormatReader

I think FILE_SHARE_READ/FILE_SHARE_WRITE is not about whether the file is opened in readOnly or readWrite but rather whether anyone else is allowed to open the file in that way. It seems you can provide read-only protection using the parameter to CreateFileMapping.

Maybe someone could double check my logic here - but I think it’d be better if CreateFile was opened with FILE_SHARE_WRITE unless exclusive was set.

HANDLE h = CreateFile (file.getFullPathName().toWideCharPointer(), accessMode,
                       exclusive ? 0 : FILE_SHARE_WRITE, 0,
                       createType, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN, 0);

Well spotted. The windows code is also not in line with what the posix version of the code does, i.e. the posix code uses mmap and allows other code to access the same memory mapped file with higher privileges than the original creator of the map.

This is now fixed on develop with commit b83bf4e.

1 Like

Nice one. You had a look at my AudioBuffer<> bug as well now? :slight_smile:

One by one, I’ll get to it, don’t worry…

1 Like

I worry a little bit that stuff gets lost in the forum :slight_smile: It might not be the case … but I worry :slight_smile:

1 Like

Opening the same file for reading multiple times no longer appears to work when the file is already opened into a MemoryMappedAudioFileReader. At least the Windows native file dialog (invoked from Juce’s FileChooser) gives an error that the selected file is already open. Seems like it’s not just an issue with the Windows native file dialog complaining, opening the same file programmatically does not work either.

Thanks @Xenakios. @jimc you did not run into this issue? Any workaround?

In any case, I wonder if I should avoid opening the same file multiple times anyway? Maybe I should have some kind of a cache/pool object that has the MemoryMappedAudioFileReaders only for unique files? edit : Well, I implemented that cache thing…But of course that doesn’t help with the Windows native file chooser dialog complaining and preventing from choosing the file.

I was opening for writing with a non-memory mapped set up, and then for reading just the once, so didn’t hit this issue.

Presumably it must be possible … ? If i get a moment I’ll try a test but don’t wait for me - got a million deadlines :frowning:

Sorry @jimc, I think I will need to revert this commit as it’s causing problems.

I’m in no hurry - maybe just open a ticket for it for a future day… :slight_smile: