Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Add missing FileSystemWatcher methods#13656

Merged
ianhays merged 1 commit intodotnet:masterfrom
ianhays:api_fsw
Nov 17, 2016
Merged

Add missing FileSystemWatcher methods#13656
ianhays merged 1 commit intodotnet:masterfrom
ianhays:api_fsw

Conversation

@ianhays
Copy link
Copy Markdown
Contributor

@ianhays ianhays commented Nov 14, 2016

Adds source and tests for the remaining missing members in FileSystemWatcher. This required that FileSystemWatcher take a dependency on System.ComponentModel.TypeConverter.

resolves https://github.com/dotnet/corefx/issues/13491

@AlexGhiondea @danmosemsft @joperezr @alexperovich @JeremyKuhne

@danmoseley
Copy link
Copy Markdown
Member

        }

base.Dispose(disposing)
in desktop


Refers to: src/System.IO.FileSystem.Watcher/src/System/IO/FileSystemWatcher.cs:386 in 595aa0d. [](commit_id = 595aa0d, deletion_comment = False)

protected void OnRenamed(RenamedEventArgs e)
{
_onRenamedHandler?.Invoke(this, e);
RenamedEventHandler handler = _onRenamedHandler;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

InvokeOn(e, _onRenamedHandler);

@@ -473,7 +496,14 @@ protected void OnDeleted(FileSystemEventArgs e)
[SuppressMessage("Microsoft.Security", "CA2109:ReviewVisibleEventHandlers", MessageId = "0#", Justification = "Changing from protected to private would be a breaking change")]
protected void OnError(ErrorEventArgs e)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

InvokeOn(e, _onErrorHandler);

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't use the InvokeOn helper for Renamed and Error because of the different handler/args types that do not share a common parent.

public void EndInit()
{
_initializing = false;
//Start listening to events if _enabled was set to true at some point.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: space after //

}
}

/// <summary>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name/comment of this test and the one below are switched

_enabled = false;

if (IsSuspended())
return;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When will the subsequent logic be invoked in this case?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't be. When under initialization, the only action StopRaisingEvents does is to set _enabled to false since actual event watching is paused/stopped/hasn't begun.

This state is reached by first called BeginInit() which will call StopRaisingEvents before setting _enabled, so before we get into an IsSuspended state we will have done the subsequent cleanup necessary.

So the assertion is that when IsSuspended is true, we already did the other stuff in StopRaisingEvents and don't need to do it again.

This is ripped from the desktop code.

{
if (handler != null)
{
if (SynchronizingObject != null && SynchronizingObject.InvokeRequired)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is happening in a queued work item, right? What happens if SynchronizingObject is changed from null to non-null between these checks or after these checks and before the BeginInvoke call?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same could be said for the handler changing from non-null to null between the check and the invocation, yeah?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

handler is a local

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah, we're not using the _onXHandlers directly.

The SynchronizingObject thing is potentially an issue and one that is present in desktop as well. We can't exactly catch the nullreference here because it's possible that the SynchronizingObject.BeginInvoke implementation may throw that in which case we don't want to mess with it. It also doesn't seem like we would want to copy the object or lock around it either, but I'm not too familiar with this synchronization scheme.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just put it in a local, e.g.

ISynchronizeInvoke syncObj = SynchronizingObject;
if (syncObj != null && syncObj.InvokeRequired) { ... }

"System.Runtime": "4.4.0-beta-24714-01",
"System.ComponentModel.Primitives": "4.4.0-beta-24714-01"
"System.ComponentModel.Primitives": "4.4.0-beta-24714-01",
"System.ComponentModel.TypeConverter": "4.4.0-beta-24714-01"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4.4.0-beta-24714-01 [](start = 44, length = 19)

Just as FYI, whenever adding dependencies like in here, make sure that you rebase and update the dependency version before merging, since it is likely that they will change from the moment you sent out your review to the moment you merge.


// Used for synchronization
private bool _disposed;
private ISynchronizeInvoke synchronizingObject;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: _synchronizingObject

Adds source and tests for the remaining missing members in FileSystemWatcher. This required that FileSystemWatcher take a dependency on System.ComponentModel.TypeConverter.
@danmoseley
Copy link
Copy Markdown
Member

danmoseley commented Nov 16, 2016

Not sure what needs to be done here. @mmitche is this a setup issue?

error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using the v100 build tools, please install Visual Studio 2010 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [D:\j\workspace\windows_nt_de---4526f5ff\src\System.ServiceProcess.ServiceController\tests\System.ServiceProcess.ServiceController.TestNativeService\System.ServiceProcess.ServiceController.TestNativeService.vcxproj]

@joperezr
Copy link
Copy Markdown
Member

@dotnet-bot test Innerloop Windows_NT Debug Build and Test please (bug in the build has been fixed)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FileSystemWatcher missing some NS2.0 methods

6 participants