Skip to content

Use Cases

Paul Salmon edited this page Jun 20, 2022 · 3 revisions

I currently use File Watcher to monitor the data files stored on my server. Most of the files are family photos and videos, which I can't replace if they were lost. Other files are a mix of various data files, but I also monitor those files, as well.

Below are a list of different use cases for FileWatcher that I currently employ to monitor my files.

Monitor Family Photos and Videos

For my family photos and videos, I always keep the original files, and don't make any changes to those files directly. Any changes are made to copies of the files, and are then saved in addition to the originals, if the changes need to be saved.

I have setup File Watcher to alert me if any photos or videos are created, modified, renamed, or deleted. This is done by sending a message to my Gotify server that includes the full path to the file that was changed. I use the Notification element to send the message to the Gotify server on any change.

In addition, if a file is created I call the File Verification application to generate a hash of the file and store it in the same folder as the file. This is done using the Command element with the Create trigger.

The watch XML config for the photos watch is shown below:

<watch>
    <path>I:\Pictures</path>
    <timeout>300</timeout>
    <exclusions>
        <files>
            <name>__fv.txt</name>
        </files>                  
        <attributes>
            <attribute>System</attribute>
        </attributes>            
    </exclusions>
    <notifications>
        <notification>
            <url>http://[Gotify Server]/message</url>
            <method>POST</method>
            <triggers>
                <trigger>Change</trigger>
                <trigger>Create</trigger>
                <trigger>Delete</trigger>
                <trigger>Rename</trigger>
            </triggers>
            <data>
                <headers>
                    <header>
                        <name>X-Gotify-Key</name>
                        <value>AAA-A-AAA-A-AA</value>
                    </header>
                </headers>
                <body>
                    {
                        "message": "[message]",
                        "priority": 7,
                        "title": "Pictures Folder"
                    }            
                </body>
            </data>
        </notification>
    </notifications>
    <commands>
        <command>
            <triggers>
                <trigger>Create</trigger>
            </triggers>                      
            <path>C:\Tools\fv\fv.exe</path>                 
            <arguments>-f "[exactpath]"</arguments>
        </command>
    </commands>                   
</watch>

The above shows an exclusion for a file named __fv.txt. This is the default checksum name of the file generated by File Verification, so I exclude it so as it changes (more checksums added) it won't be processed.

Moving Files From Staging

To help prevent me from overwriting data, the data share mapping is always read-only. For me to update files, I use a staging share that is writeable. Once the files are written to the staging share, they are then moved to the actual data share on the server-side.

To facilitate the file move, I use File Watcher to monitor the staging share, and then move the files to the final destination folder. The watch XML structure is simple. I specify the staging path and perform a move action when a file is created. The source path is the staging location of the file, and the destination is the location of the read-only share location (writeable on the server). I always set the verify element to true as I want to make sure the source and destination files match.

The XML for this watch is shown below:

<watch>
    <path>C:\Staging\Backup\Pictures</path>
    <exclusions>                    
        <attributes>
            <attribute>System</attribute>
        </attributes>            
    </exclusions>
    <actions>
        <action>
            <triggers>
                <trigger>Create</trigger>
            </triggers>              
            <type>Move</type>
            <source>[exactpath]</source>
            <destination>i:\Pictures\[fullpath]</destination>
            <verify>true</verify>
        </action>
    </actions>          
</watch>

The moving files from staging to the destination will cause File Watcher to execute the watch in the first use case as that watch is monitoring the destination of the staging watch. So once the file has been moved from the staging folder, the other watch will send a notification to my Gotify server, and then generate a hash of the file.

Clone this wiki locally