Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InternalStreamReader FileAccess to ReadWrite #343

Closed
LordPinhead opened this issue Apr 23, 2019 · 4 comments
Closed

InternalStreamReader FileAccess to ReadWrite #343

LordPinhead opened this issue Apr 23, 2019 · 4 comments
Assignees
Milestone

Comments

@LordPinhead
Copy link

Based on Issue #248, is there a reason not to change the FileStream Constructor to use FileShare.ReadWrite? I know i could use a Stream directly to avoid errors while Excel locks the file, but i whould think Reading should not be stopped because someone forgot to close the file. I try´d it with this Option and have no negative impacts other than "The File could be changed by Excel while reading", that is the only downside i can think of.

@netniV
Copy link
Contributor

netniV commented Apr 25, 2019

@LordPinhead: I have an workaround with an FileStream an StreamAccess ReadWrite, so i can open it. I opened an Issue on Github to ask if there is any reason not doing this by default.

using (var stream = new FileStream(DataFile.FullName, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
  using (var reader = new StreamReader(stream)) {
    engine.ReadStream(reader).ToList().ForEach(record => {
      // Do Something
    });
  }

I'll be honest, I'm surprised that works given that Excel has a write lock already on it. My text editors that handle locking (marking the file as readonly) for most scenarios won't even open an Excel locked file.

FileShare.Read is the default for those FileStream constructors without a FileShare parameter so maybe they aren't specifying it either.

The only concern I would have is when another process has the ability to write to a file we are trying to read, that could lead to data corruption issues in what we are trying to read. So given this I, personally, wouldn't feel it's correct use that by default in most scenario's.

Links to what I read, though these are the .NET Framework, I think the same would apply to core.

https://docs.microsoft.com/en-us/dotnet/api/system.io.filestream.-ctor?view=netframework-4.8#System_IO_FileStream__ctor_Microsoft_Win32_SafeHandles_SafeFileHandle_System_IO_FileAccess_

https://docs.microsoft.com/en-us/dotnet/api/system.io.fileshare?view=netframework-4.8

@mcavigelli mcavigelli added this to the 3.4.2 milestone Oct 14, 2020
@mcavigelli mcavigelli self-assigned this Oct 21, 2020
@mcavigelli
Copy link
Collaborator

mcavigelli commented Oct 31, 2020

I'm not sure if I understand the suggestion: are you suggesting to change

        var stream = new FileStream(path,
            FileMode.Open,
            FileAccess.Read,        // old
            FileShare.Read,
            bufferSize,
            FileOptions.SequentialScan);

        var stream = new FileStream(path,
            FileMode.Open,
            FileAccess.ReadWrite,    // new
            FileShare.Read,
            bufferSize,
            FileOptions.SequentialScan);

Matthias

@netniV
Copy link
Contributor

netniV commented Nov 2, 2020

No, I think he was after the row below, FileShare to be read/write, so that other files can have a write lock.

@mcavigelli
Copy link
Collaborator

mcavigelli commented Nov 4, 2020

Thank you for your clarification. It is included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants