We have a python application that checks a directory(C:\sample\folder) every 5 seconds, there's also this external application(.net app) that puts file into that same directory (C:\sample\folder).
Will there be any conflict when the two application access the same folder at the same time (accidentally)?
Conflicts like :
the external app wont be able to place a file because the python app is currently walking through that same directory?
It should be fine for the external app to create and write to a file. If the Python app is reading a file, the .NET app may not be able to write to it while Python is reading it, without both processes opening the file in a shareable way, however.
Likewise if the Python app is going to start reading the newly-created file, it may either find that it can't do so until the .NET app has finished writing to it, or it may read incomplete data. Again, changes would quite possibly be required to both processes to allow reading at all.
It's worth thoroughly testing all the poosibilities you're concerned about, possibly involving the creation of a "fake" external app which writes to a file very slowly, but opening it in the same way that the real one does.
Related
I want an auto updater that detect modified game files (by comparing files on the client-side and a server) and only download modified files.
The scenario is that there's about one thousand clients in a network, that use same application. If a new version of the application is available, they all have to get the new version.
I see a www.aldera.to game if you install the files their Aelra_patcher application auto patch the files from the server side. It do the exact thing I want:Getting the newest files from server when the patcher is run. But the problem is that clients wrote in C#, and I can't use IcePatch2 inside my application.
So far, the best solution I found is to get .NET Application Updater Component and customize it to fit my needs. But I prefer a solution that dose not require me to maintain another application.
Any idea?
Managing file locks is fairly simple. The process should go something like this:
The game application downloads the installer, if there is any
The game application runs the installer and exits
The installer starts doing the work of updating files as needed. If any files are locked it may wait a short while and try again, or ask the user if it is ok to close the application that have locked the files.
But the topic of minimizing update time and bandwith is a fairly complex. You might want to read Raymon Chens articles on Windows Update Formats to get some appreciation for the various issues.
I'm not familiar with IcePatch2, but it seems to be a fairly generic file synchronization tool. This may be appropriate for your specific use case, but I would expect some use cases to benefit from a more specialized approach. You could for example use knowledge of things like file or resource versions to avoid much of the work a more generic tool has to do.
We have an app we wrote deployed onto our terminal servers at work, and keeping it up-to-date is a bit of a pain.
What update mechanisms do people use for app on terminal servers? At the moment we manually copy the new exe + dependencies on witch is just rubbish.
I'm a bit concerned about files being locked by users when trying to update, i cant really just kill the process in case someone is in the middle of doing something. We would like to be able to handle the odd fat client update as well.
Ideally we'd plug something into teamcity/octopus but are open to suggestions
Create a script that copies the exe file to a user specific temp folder, then launches the copied exe. To make the script more efficient, you can have it check the dates of the files. If they are different, then you copy the file over the old one located in the temp folder, else you just launch it.
There are several threads on SO that describe how to check which application creates a file with tools like Sysinternals process monitor. Is something like this possible programmatically from .net?
Background: My program has to remote-control a proprietary third party application using its automation interface, and one of the functions I need from this application has a bug where it creates a bunch of temporary files in %TEMP% that are called tmpXXXX.tmp (the same as .net's Path.GetTempFileName() does) but does not delete them. This causes the C drive to become full over time, eventually failing the application. I already filed a bug to the manufacturer, but we need a temporary workaround for the time being, so I thought of putting a FileSystemWatcher on %TEMP% that watches tmp*.tmp, collects these files, and after the operation on the third-party application finishes, deletes them. But this is risky as another application might also write files with the same file name pattern to %TEMP% so I only want to delete those created by NastyBuggyThirdPartyApplication.exe.
Is this anyhow possible?
This kind of things is possible, but maybe a bit tricky.
To know who created the file, look at the user that owns it. Therefore you might need to create a specific user, and that application will run under this specific user. In order to do that, you need to create a small application that will start your buggy app by impersonating another user, so anything done within the app will be under this user so as file creating...
I don't know how to monitor and get triggered when a file is created, but nothing can prevent you from setting a timer that wakes up every five or ten minutes, then checks if any file in the directory is owned by the application user and closed, so it deletes it.
Maybe if they react fast for this bug fixing, you won't need your app very long time. So another solution, if possible might just to change the Temp folder into another drive, which has lots of space...
One solution is that you use a FileWatcher to automatically delete all the files but before deleting you should check if the file is not currently locked or used by other process, for example the Sysinternal Suite has a tool called handle.exe that can do this. Use it from the command line:
handle.exe -a
You can invoke this from a c# program (there might be some performance issues though)
So what you would do is when a file is created you verify if it is in use or locked (for example u can use the code provided in Is there a way to check if a file is in use?) and then delete it.
Most of the time when an app is using a temp file it will lock it to prevent just what you fear, that you might delete files from other processes.
As far as I can tell there is no sure way to identify which process created a specific file.
I am looking for a programmatic way to copy files from one network drive to another. I have created a program that does a simple copy but this is not enough as the line is not reliable and the files ends up being corrupted. Is there a technology that syncs the folders and does a sum-check or something like that.
I need it to be a c# app as I need to know when the copy is completed so I can process the files on the other side. I am using windows services to co-ordinate this.
I'm just looking for someone to point me in the right direction with tutorials if necessary.
What you are looking for is Robocopy (aka Robust Copy), it is built in to windows Vista and newer and it has features to retry on network failure.
One down side is there is no "Verify" functionality built in, but if you need to you can use a 3rd party file hashing program and put the copy in a script that verifies the hashes after the copy completes.
Here is a query that copies all files and sub-folders in a restartable mode, if a copy fails it will re-try 1,000,000 times by default waiting 30 seconds between tries. (you can change that with /r:<N> and /w:<N> where <N> is a number)
robocopy C:\SourceFolder \\DestComputer\DestFolder /zb /e
The only time I have ever done anything like this has been during the deploy process to distributed servers. In that instance I zipped the files, moved and unzipped them using PSEXEC.
If I were you, I would begin by figuring out how to zip the files (To prevent the corruption issues you have described) and then worry about how to move them.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Embedded a *.exe into a dll
I have a C# project - a class library - that produces a DLL file.
From within itself, this project runs an external .exe file. (Using the standard Process stuff, and it works fine.)
However, my question is: How can I bake the external .exe file into the project, such that the end-consumer will only receive the final DLL file, without ever seeing the .exe file itself?
This will make my client happier, as he will continue receiving one DLL file (as before, before I needed the .exe).
If you are going to launch it as an external process, it needs to exist on disk. It could be embedded in the .dll as a resource and extracted on-demand.
Your best bet would be to make the exe an embedded resource.
If your client needs the .exe at runtime, you'd darn well better make sure he has a copy of the .exe. IMHO...
PS:
You can "trick" the client by embedding your .dll as a resource (as a "Trojan horse"), and then extracting it at runtime. Which, IMHO, would be stupid. Expensive. And risky.
If you need the .exe, ship the .exe. And be explicit about it.
If the client expressly refuses to have an .exe - then your implemention violates the requirements, and you need to go back to the drawing board.
The "exe-as-resource" workaround ... is a lie and a cheat. And it isn't even a very efficient or safe cheat.
ALSO:
Embedded a *.exe into a dll
On a side note, remember that when you pull a file from your resources
to disk and then execute code on it, you may trigger Windows Data
Execution Prevention - basically, Windows tries to automatically
detect if something is supposed to be code or data, and if it looks
like data (which a resource would), then it will prevent that data
from being executed as code.
This becomes a particularly sticky issue if your .NET assembly is
going to be used over a network instead of from a local drive - there
are all sorts of .NET security configurations that might prevent this
from working correctly.