I was curious how the FileSystemWatcher worked and found the answer here very helpful. Since Windows raises a flag I wonder if I can effectively use FileSystemWatcher on a mapped drive that is on a remote machine? If so, what kind of permissions do I need? I only have access to part of the harddrive (the manufacturer of the machine did this so I can copy log files off the harddrive). I have no access to the OS on the remote.
FileSystemWatcher is not 100% reliable under any circumstances, although it is usually acceptable with local folders. However, network shares can disconnect, have added latency, isn't being completely monitored by your local client Windows, etc.
Polling is about the only reliable way to check the folder. "Wear and tear" is not a problem since there are plenty of other processes, including Windows, that do a much higher amount of I/O. Also, drives are cheap.
Related
I have an existing windows service that uses FileSystemWatcher object to monitor one folder. Now, I would like to create another windows service that uses the FileSystemWatcher object to monitor the same folder. So, can someone please clarify me on below questions ?
Is there a restriction on number of FileSystemWatchers monitoring the same folder ?
how do we handle the file lock or access issues such as when one FileSystemWatcher is being written to the directory and the other is trying to read the same file ?
Any other implications on this set-up?
Regards,
Ram
I am dealing with a similar situation. I have the same service installed and running on 2 machines. Each is monitoring the same collection of folders on a network.
In my experience:
Having 2 services each monitoring the same network share location(s) is not a problem - both will react.
My FSW triggers a file-copy from the monitored location to another network location. Since both instances of the service react, both will attempt the copy. One of my services throws an error (which I try..catch) the other does the work. This is a satisfactory solution for me although I appreciate it's not very "tidy".
The FSW is remarkably unreliable. I'm currently dealing with a situation where the network connection fails and I'm having to restart my filewatchers. there are plenty of examples of ways to restart a FSW on SO... Personally, I'm setting off a timer in the onError event and recreating my FSW(s) after 30 seconds. Yes, I'm recreating it - i read advice that a simple ".EnableRaisingEvents=true;" would not work well enough.
HTH
How can I get information of deleted file(s) in Windows,which a user deleted file/folder over share network?
Is there a place where Window Logs all such information. If yes then where?
Can we trace such detail programmatically using c# ?
No, there is normally no evidence after the fact of file deletion activity. There are no logs made unless you have an application that does the logging.
If you need to track file deletions you can do so using the FileSystemWatcher class. It will only tell you what is changed however not who did the changes, and will only track changes on the local filesystem. For a network share that means you have to be running on the server that hosts the share.
For tracking who did the deletion on a network share the only option I can think of is to use network packet inspection. This is quite resource expensive and involved, as it will require you to manually reassemble and interpret SMB messages. Not simple. If you really want to try this then WinPcap (via something like SharpPcap or PcapDotNet) will give you access to the packets, and do a lot of reading on the SMB protocol.
Just be aware that those are some pretty deep waters to be jumping into.
Basically, I am making a program that blocks the internet access after 11h PM. But my only problem is that there is many ways to bypass it, such as shutting down the computer and the user just have to wait until the process gets closed by the OS itself then cancel the shutdown operation (Windows 7).
Any ways to make sure that the program won't get terminated before the pc shutdowns or anything?
If your goal is to block internet access, I recommend enforcing this rule on your router rather than on your PCs. It would be a much simpler, much more reliable solution. Your router probably already supports the feature, but if it doesn't you can buy a new consumer-grade router (dirt-cheap) and/or install a custom firmware that does (see Tomato Firmware for the Linksys WRT-54GL and company).
If the router approach just won't work for you, and you must block internet access in software, I would first suggest investigating Windows "local policy" or "group policy" to see if they can do what you want.
If that's too complex for your taste, try finding an off-the-shelf solution. Look into ZoneAlarm or NetNanny to see if one of them will do the trick.
But if you are bent on writing a C# program to do it for you, you probably want to look into writing a Windows Service. Services are more complex to write and deploy, but they can be configured to run at boot and are not slaved to a user session like regular desktop apps.
That's actually somewhat complex. It's like a virus - how do you keep it running, always?
You might want to read about drivers. Drivers have the highest "trust" by the operating system. They can physically access anything in the computer. Anything but a driver or a core file may be closed by the user manually, is some way or another.
Another thing you can do is to "burn" the file into Kernal.DLL or such. You can do it with a different operating system on the computer (e.g Linux) or by physically writing to the hard disk (not via Windows's API). To physically access the driver, check this out.
I understand that you can run .NET application from network share. I have done so many times and it works. My question is relating to performance. Will the app run slower with 10 concurrent users than with 2? Is there some magical number of concurrent users that provides a rule-of-thumb saying if you have more than 20 users don't host the app this way?
Does each client copy the app and run from the copy in a temp folder? Or are they each accessing the source file? Where does Application.ExecutablePath point in this situation?
EDIT: There is no Access database involved. All data persistance will be handled through an SQL server database with stored procedures, etc.
The executable is copied from the Windows share to the memory of the workstation computer, and executed there. There shouldn't be any discernible difference in performance, assuming the executable itself has no sharing issues.
Of course, if your app is sharing a database, there might be concurrency issues there, but that has nothing to do with where the workstation gets the executable.
Application.ExecutablePath will point to the folder on the network share. Environment.SpecialFolder.Desktop should still point to the workstation.
The Problem
Our company make specialized devices running Windows XP (Windows XPe, to be precise). One of the unbending legal requirements we face is that we must quickly detect when a fixed IDE drive is removed. Quickly as in within a few seconds.
The drives in question are IDE drives. They are also software-protected from writes with an EWF (Enhanced Write Filter) layer. The EWF layer sits under the file system, protecting the disk from writes. If you change or write something on an EWF-protected volume, the actual changes happen only in a memory layer (but the file system isn't aware of that).
The problem is that Windows itself doesn't seem to notice fixed drive removal. You can pull the drive out of the machine, and Windows Explorer will be happy to let you browse directories and even open files if they happen to still be cached in memory. And thanks to the EWF layer, I can even seem to write files to the missing drive.
I need a clean software-only solution. Ideally in C#/.Net 1.1, but I have no problem with using pinvoke or C++.
Things I can't do
No, I can't retrofit thousands of devices with new hardware.
No, we can't just super-glue drives in to meet legal requirements.
No, a normal file write/read won't detect the situation, thanks to the EWF layer.
No, we can't turn off the EWF layer.
No, I can't ignore legal requirements, even if they are silly.
No, I can't detect fixed drive removal the way I would for a USB or other removable drive. These are fixed drives.
No, I can't use WMI (Windows Management Instrumentation). It isn't installed on our machines.
No I can't use versions of .Net past 1.1. It won't fit on our small drives. (But if an easy solution exists in a higher version of .Net, I might be able to port it back to 1.1.)
Current awkward solution
I'm not happy with our current solution. I'm looking for something more elegant and efficient.
What I'm currently doing involves two threads.
Thread A polls the drive. It first creates a special file on the drive using Kernel32.dll:
Kernel32.CreateFile(
filename,
File_Access.GenericRead | File_Access.GenericWrite,
File_Share.Read | File_Share.Write,
IntPtr.Zero,
CreationDisposition.CreateAlways,
CreateFileFlagsAndAttributes.File_Attribute_Hidden | CreateFileFlagsAndAttributes.File_Attribute_System,
IntPtr.Zero);
Then it polls the drive by calling
Kernel32.FlushFileBuffers(fileHandle);
If the drive has been removed, then thread A will hang for a long time before returning an error code.
Thread B polls thread A.
If thread B sees that thread A has locked up (hasn't updated a special variable in a while), then thread B raises an event that the drive has been removed.
My current solution works, but I don't like it. If anyone knows a cleaner software-only solution, I would appreciate it.
I'm shocked and amazed that the system doesn't fall over dead if you yank out a fixed IDE drive. Like, really shocked. But, hey...
Are you sure can't just fix this with super glue? :)
First, the reason why Windows doesn't notice is because notification of device removal has to come from the bus driver. In this case, the IDE bus doesn't support what we call "surprise remove" so no one ever gets told that the disk is unplugged. I suspect that communications just start timing out, which is why your flush trick works.
Not sure if you're going to come up with any cleaner solution though. If you really, really need this and can restrict it to just a particular release of XP, someone might be able to analyze the drivers involved here and exploit a path that would give you a quicker result. But there's clearly nothing architected in Windows to deal with this and so that's like real work.
-scott
Have you looked in here:
http://msdn.microsoft.com/en-us/library/aa363217(VS.85).aspx
Looks like what you are looking for.