[Mono-dev] FileSystemWatcher Issue?
Rick Tillery
rtillerywork at gmail.com
Mon Jul 31 18:22:36 UTC 2017
I'm sorry, I neglected to specify the environments:
mono 5.0.1.1
CentOS 7 & Ubuntu 16.04
Rick
On Mon, Jul 31, 2017 at 11:46 AM, Rick Tillery <rtillerywork at gmail.com>
wrote:
> In conjunction with "Sync of mono Cert Store," I'm trying to utilize
> FileSystemWatcher to monitor the system certificate file for changes (which
> will trigger a cert-sync).
>
> Since some distros use the legacy address (/etc/pki/tls/certs/ca-bundle.crt)
> as a symbolic link, and modification of the system cert store appears to be
> a free-for-all between using the update-ca-trust
> <http://www.unix.com/man-page/centos/8/update-ca-trust/> or
> update-ca-certificates
> <http://manpages.ubuntu.com/manpages/precise/man8/update-ca-certificates.8.html>
> scripts, running other utilities
> <https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Managing_the_Certificate_Database.html>,
> modifying the file directly
> <https://www.happyassassin.net/2015/01/14/trusting-additional-cas-in-fedora-rhel-centos-dont-append-to-etcpkitlscertsca-bundle-crt-or-etcpkitlscert-pem/>,
> and even replacing the file completely
> <https://techjourney.net/update-add-ca-certificates-bundle-in-redhat-centos/>,
> I have been testing as many file manipulation combinations as I can
> imagine, to ensure FileSystemWatcher catches them all.
>
> In doing so, I found an issue in FileSystemWatcher.
>
> To handle the symbolic link case, FileSystemWatcher objects are set up for
> each file in the chain, symbolic link and target alike. In one test, the
> target of a symbolic link is replaced by another file using mv. But
> FileSystemWatcher does not register the change. Oddly, if only a watch of
> the target file is registered, FileSystemWatcher registers the change.
>
> The code I'm using is attached. Here is what I see on command line:
>
> (console1) ~$ echo >bar "test"
> (console1) ~$ echo >foobar "test1"
> (console1) ~$ ln -s bar foo
> (console1) ~$ ll
> total 24
> -rw-rw-r--. 1 rtillery rtillery 5 Jul 31 11:06 bar
> lrwxrwxrwx. 1 rtillery rtillery 3 Jul 31 11:06 foo -> bar
> -rw-rw-r--. 1 rtillery rtillery 6 Jul 31 11:06 foobar
> -rwxrwxr-x. 1 rtillery rtillery 5632 Jul 31 11:05 fsw.exe
> (console1) ~$ mono fsw.exe ./bar
> Watching: /home/rtillery/bar
> bar watching ENABLED
> Press 'Q' to quit
>
> (console2) ~$ mv foobar bar
>
> (console1)
> File: /home/rtillery/foobar renamed to /home/rtillery/bar
>
> ...
>
> (console1) ~$ mono fsw.exe ./foo
> Watching: /home/rtillery/foo
> Watching: /home/rtillery/bar
> foo watching ENABLED
> bar watching ENABLED
> Press 'Q' to quit
>
> (console2) ~$ echo >foobar "test"
> (console2) ~$ mv foobar bar
>
>
> Nothing appears on console 1 in the second case, but I don't really see
> why. I believe I'm setting up the watches in exactly the same way, except
> that there are two instead of one. Is this a problem with
> FileSystemWatcher? Code is below.
>
> Thanks,
> Rick
>
> using System;
> using System.Collections.Generic;
> using System.IO;
> using Mono.Unix;
>
> // Compile with "mcs fsw.cs /r:Mono.Posix.dll"
>
> public class FSW
> {
> private static IDictionary<string, FileSystemWatcher> watches = new
> Dictionary<string, FileSystemWatcher>();
>
> public static void Main()
> {
> string[] args = System.Environment.GetCommandLineArgs();
> if (args.Length != 2)
> {
> System.Console.WriteLine("USAGE: (mono) fswtest(.exe)
> file_to_watch");
> goto Error;
> }
>
> SetUpWatch(args[1]);
>
> Console.WriteLine("Press \'Q\' to quit.");
> while(Console.Read() != 'q')
> ;
>
> Error:
> ;
> }
>
> private static void SetUpWatch(string file)
> {
> do
> {
> AddWatch(file);
> file = GetSymbolicLinkTarget(file);
> }
> while (file != null);
> EnableWatches();
> }
>
> private static void AddWatch(string file)
> {
> FileSystemWatcher watcher = new FileSystemWatcher();
> watcher.Path = Path.GetDirectoryName(file);
> watcher.NotifyFilter = 0
> // | NotifyFilters.Attributes
> // | NotifyFilters.CreationTime
> | NotifyFilters.DirectoryName
> | NotifyFilters.FileName
> | NotifyFilters.LastAccess
> | NotifyFilters.LastWrite
> // | NotifyFilters.Security
> // | NotifyFilters.Size
> ;
> watcher.Filter = Path.GetFileName(file);
> watcher.Changed += new FileSystemEventHandler(OnChanged);
> watcher.Created += new FileSystemEventHandler(OnChanged);
> watcher.Deleted += new FileSystemEventHandler(OnChanged);
> // watcher.Disposed // Occurs when the component is disposed by a
> call to the Dispose method. (Inherited from Component.)
> // watcher.Error // Occurs when the instance of FileSystemWatcher
> is unable to continue monitoring changes or when the internal buffer
> overflows.
> watcher.Renamed += new RenamedEventHandler(OnRenamed);
> watches.Add(Path.GetFullPath(file), watcher);
> Console.WriteLine("Watching: " + Path.GetFullPath(file));
> }
>
> private static string GetSymbolicLinkTarget(string file)
> {
> UnixSymbolicLinkInfo link = new UnixSymbolicLinkInfo(file);
> return link.HasContents ? link.GetContents().FullName : null;
> }
>
> private static void EnableWatches()
> {
> foreach (KeyValuePair<string, FileSystemWatcher> watch in watches)
> {
> watch.Value.EnableRaisingEvents = true;
> Console.WriteLine("" + watch.Value.Filter + " watching ENABLED");
> }
> }
>
> private static void OnChanged(object source, FileSystemEventArgs
> eventargs)
> {
> Console.WriteLine("File: \"" + eventargs.FullPath + "\" -- " +
> eventargs.ChangeType);
> }
>
> private static void OnRenamed(object source, RenamedEventArgs
> eventargs)
> {
> Console.WriteLine("File: {0} renamed to {1}",
> eventargs.OldFullPath, eventargs.FullPath);
> }
> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170731/1e9e769b/attachment.html>
More information about the Mono-devel-list
mailing list