Shulou(Shulou.com)06/02 Report--

problem

Recently, the company moved its file server to Nasuni, a cloud service provider. The initial feedback on the use of this platform is OK, and the performance, automatic backup and so on are all good, but in the last two weeks, there has been a bug. When an OSX user creates a new folder, he will automatically create new permissions from time to time, thus making it impossible for users to access the contents of the folder.

For example, the permissions inherited by a newly created folder are automatically tampered with and Special restrictions are automatically added

The compatibility of the OSX system with smb is estimated to be one reason, and the design of the platform itself is also estimated to be a problem. But no matter which one is the culprit, it is not a problem that can be solved in a short time, so Douzi must come up with a temporary solution.

Solution

I discussed with my colleagues that you can reset the permissions of the new folder through the script. In short, this requires real-time monitoring of the entire file system (or a folder), and once a new folder or file is created below, the permissions of that file or folder are reset.

How can this thing be realized? We can consider event-based PowerShell scripts. The event-based script is quite different from the traditional process-based script, which can be understood as the traditional way of writing, we need to tell the system to do something, while the event-based way is that the event occurs, it will trigger a callback function to execute a behavior.

This event-based approach mainly involves three concepts: Subscriptions (subscription), registrations (registration), and actions (behavior). We can subscribe to an event and get notified when it occurs, which needs to be registered at the specified source identifier (source identifier), and then for each event, when it occurs, we can bind a behavior.

For example, first create an object for file system operation

$fw=New-Object IO.FileSystemwatcher

Pay attention to the events, methods and properties of this object

We can manually specify the events and properties that we intend to observe

such as

$fw.Filter='*'

Or a more direct way is to specify all of them when you create them.

$folder ='c:\ temp' $filter ='*. *'$fsw = New-Object IO.FileSystemWatcher $folder, $filter-Property @ {IncludeSubdirectories = $true;NotifyFilter = [IO.NotifyFilters] 'DirectoryName,FileName, LastWrite'}

Among the attributes shown above, the more important ones are the following:

Filter: specify which types of files or folders need to be watched

Includesubdirectories: whether to query all subfolders recursively

Notifyfilter: specify which types of attributes require attention, including the following

Then we can register the event and specify the corresponding behavior

Register-ObjectEvent-inputObject $fsw-EventName created-SourceIdentifier FileCreated-Action {...}

When we register an event, he will create a background job by default, and when the job captures the first result, he will execute the corresponding behavior.

Test script

Here is a demo script

# specify the directory $folder ='c:\ temp'# wildcard, indicating that all item require attention. $filter ='*. *'# initialize objects, specify attributes, paths, etc. $fsw = New-Object IO.FileSystemWatcher $folder, $filter-Property @ {IncludeSubdirectories = $true NotifyFilter = [IO.NotifyFilters] 'DirectoryName,FileName, LastWrite'} # cancel the existing registration Unregister-Event FileCreated # registration event Binding behavior Register-ObjectEvent-inputObject $fsw-EventName created-SourceIdentifier FileCreated-Action {$Event | out-host $name = $Event.SourceEventArgs.Name $folderpath = $Event.SourceEventArgs.FullPath $changeType = $Event.SourceEventArgs.ChangeType $actionby = (get-item $folderpath). Getaccesscontrol (). Owner $timeStamp = $Event.TimeGenerated Write-Host "The file'$folderpath' was $changeType at $timeStamp by $actionby"-fore green Write-Host "Resetting Permission" Icacls $folderpath.ToString () / reset / t Write-Host "Finish Resetting" Out-File-FilePath c:\ Utils\ filechange-outlog.txt-Append-InputObject "The file'$folderpath' was $changeType at $timeStamp by $actionby"}

After executing, you can see that he has created a background job. The current status is not executed. Once he captures the first result, the status will become running.

When I create a new file, he detects it and automatically executes the corresponding script action, as shown below

The disadvantages of this approach are:

If the background job is executed for too long, sometimes it will not work or consume too much memory? At this time, human intervention may be needed to restart the program.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.