I am developing an application in .NET Compact Framework 3.5, for Windows CE 6. I need to automate some data synchronization between the mobile application and a PC. So what I do is that, in the .NETCF application, I have a while loop that checks every few seconds, using System.IO.File.Exists(fullFilePath), whether the file I am expecting has been copied from the PC to the mobile device, through an ActiveSync connection.
Once the mobile app finds the file, it will open and read it using a StreamReader.
My problem is that, some times, File.Exists(fullFilePath) would return true, yet the subsequent use of StreamReader may fail with a FileNotFoundException.
Ruling out the possibility of the file getting deleted between the call to File.Exists() and the instantiation of the StreamReader, would anybody know how the exception may occur? Is it because file copy through ActiveSync is not atomic, such that the file is not actually ready for reading even though File.Exists() returns true?
A file copy is most certainly not going to be atomic. When you start the copy, the file is created, but has no data in it. As the file data gets written, the file "exists", but is not yet fully complete. You'd want to know not only that it exists, but that it's not currently in use (meaning the writer is done). Trying to open it exclusively would verify that.
Related
Imagine there are 3 or more independent locations where a file can be modified. These locations communicate to each other through email or mail (direct flash drive restoration). Though there is a big room for flow - to make simultaneous editing to the file and screw up things, this client won't change too much. He rather call everyone that he is working on the last update or tell the other guys that he is waiting for third guy's last update. Anyway, at some point after several exchanges, due to one of participants unintentional error THE LAST VERSION of the file eventually gets mixed up. From this point everyone searches for the last version BY LOOKING THE CONTENT of the file.
This client wants to have a central location (he has actually, that is his PC's some location) and let everybody (including himself) copy any new or suspected new file to this location but prevent file's last version being copied. From this location he has to easily copy, send or open the file and work.
So, here is my concept (2 steps):
step 1: I made an ad to the main application where this file is created or edited. This ad prompts the user to give a version number to the file with every invoked save command from the editing application. In fact the file can be re-saved multiple times but not considered modified (file attributes creation, save etc. do not have great meaning here). This said the user can cancel my ad-in but have saved the file, not saving a new file version.
step 2: multiple solutions:
solution A: I'm thinking to have a folder/file watch and prevent the last version of the file being overwritten. As you know, FileSystemWatcher will fire the change/delete etc., events AFTER FACT so, I have to back copy overwritten file after the fact (w/ some tricks).
solution B: have a database to store all version of files and built-in some shell extension to extract/view files from the database. Move all copied/pasted files to the database (my program folder) and restore latest file in working folder after watcher fires change/delete event.
solution 3: find out built-in windows tools (API etc.) to greatly rely on it with some programming.
Any ideas?
Thanks in advance.
I want to create a file on Mac OS X (10.6) that will be deleted automatically when my process goes away. Is this possible? It would be very handy for a file locking scheme I am implementing. Preferably as a Cocoa or Carbon call.
I know that on Windows, this is possible. It's a very neat feature, but I don't know if it is something that needs to be supported by the file system.
On win32 you can call CreateFile with FILE_FLAG_DELETE_ON_CLOSE.
In .net you can create a FileStream with FileOptions.DeleteOnClose as argument.
If you are writing your own program, you could use tmpfile() call.
It creates a temporary file that get removed automatically on program termination.
You could have your app delegate to create and delete the file via the NSApplicationDelegate, however, the file would remain there if the user force quits/shut down. If force quitting is not part of your concern, then this should work. If not, you can create a simple launch agent that checks if your process exists, and if not, delete the file.
You can register an atexit() handler to delete the file, but this will not necessarily be completely reliable, particularly if the program crashes.
If you want proper file locking, consider using flock(), although, it is cooperative.
The VB.Net program in question creates several files, adds them into a zip file (using DotNetZip), and saves the zip file into a given directory (which the user chooses). This comes out just fine. But when I use it to save directly to my USB flash drive, I can't eject the drive without shutting down the program first.
I've tried disposing the zip object (from the DotNetZip library), doesn't work. I also tried setting FileIO.FileSystem.CurrentDirectory to somewhere else on the machine, still no.
In your last comment you've said that calling the 'Close' outside of the Try Catch sorted your problem, I'd recomend using a "Using" stament insted. This will close/dispose of your StreamWriter 100% of the time no matter what happens.
http://msdn.microsoft.com/en-us/library/htd05whh.aspx
I am trying to watch files in a directory to determine when files are opened/accessed. I thought FileSystemWatcher would do the trick using the event Changed.
Problem is that some applications do not create a lock on the file they open/access or change either the date modified or date accessed (even after fsutil behavior set disablelastaccess 0). Notepad for example. Apparently is makes a copy of the file in memory and plays with it there until you save it. Nor does it update the Date Accessed.
How can I monitor a directory of files and be notified when a file is simply opened/accessed by any program (e.g. Notepad)? Files may be opened from another computer, not necessarily on the computer running the "watcher".
I found lots of similar questions but did not see one focusing on file "access".
This is quite normal. Updating an existing file is quite dangerous since it can cause irretrievable data loss. A disk error (like disk full) while writing is very bad news. The common algorithm used:
rename the original file
write a new file using the original name
no error: delete the renamed file
error: delete the new file, rename original file back
Clearly this doesn't cause a Changed event to be raised, no file was changed.
Sorry, I didn't read the question well enough. There is no notification whatsoever for an app just opening a file for reading. FSW can only detect changes to the file system. There is no ready alternative either, this requires a custom file system filter driver that snoops on driver requests. Like the kind that SysInternals' ProcMon utility uses. I'm not aware of such a driver ready for use in a C# program, you can't write them in C# either. This just isn't a common requirement.
I'm creating a self updating app where I have the majority of the code in a seperate DLL. It's command line and will eventually be run on Mono. I'm just trying to get this code to work in C# on windows at the command line.
How can I create a c# application that I can delete a supporting dll while its running?
AppDomain domain = AppDomain.CreateDomain("MyDomain");
ObjectHandle instance = domain.CreateInstance( "VersionUpdater.Core", "VersionUpdater.Core.VersionInfo");
object unwrap = instance.Unwrap();
Console.WriteLine(((ICommand)unwrap).Run());
AppDomain.Unload(domain);
Console.ReadLine();
at the ReadLine the VersionUpdater.Core.dll is still locked from deletion
The ICommand interface is in VersionUpdater.Common.dll which is referenced by both the Commandline app and VersionUpdater.Core.dll
The only way I've ever managed something similar is to have the DLL in a separate AppDomain to the assembly that is trying to delete it. I unload the other AppDomain and then delete the DLL from disk.
If you're looking for a way to perform the update, off the top of my head I would go for a stub exe that spawns the real AppDomain. Then, when that stub exe detects an update is to be applied, it quits the other AppDomain and then does the update magic.
EDIT: The updater cannot share DLLs with the thing it is updating, otherwise it will lock those DLLs and therefore prevent them from being deleted. I suspect this is why you still get an exception. The updater has to be standalone and not reliant on anything that the other AppDomain uses, and vice versa.
Unwrap will load the assembly of the object's type into the appdomain that calls it. One way around this is to create a type in your "base" assembly that calls command.run, then load that into your new appdomain. This way you never have to call unwrap on an object from a type in a different assembly, and you can delete the assembly on disk.
When I built a self-updating app, I used the stub idea, but the stub was the app itself.
The app would start, look for updates. If it found an update, it would download a copy of the new app to temp storage, and then start it up (System.Diagnostics.Process.Start()) using a command-line option that said "you are being updated". Then the original exe exits.
The spawned exe starts up, sees that it is an update, and copies itself to the original app directory. It then starts the app from that new location. Then the spawned exe ends.
The newly started exe from the original app install location starts up - sees the temp file and deletes it. Then resumes normal execution.
You can always use MOVEFILE_DELAY_UNTIL_REBOOT to delete on reboot. This is most likely the least hackey way todo this sort of thing, by hackey I ususally see things like; loading up new DLL's or injecting to explorer.exe even patching a system dll to get loaded into another process, etc...
MoveFileEx From MSDN;
lpNewFileName [in, optional] The new
name of the file or directory on the
local computer.
When moving a file, the destination
can be on a different file system or
volume. If the destination is on
another drive, you must set the
MOVEFILE_COPY_ALLOWED flag in dwFlags.
When moving a directory, the
destination must be on the same drive.
If dwFlags specifies
MOVEFILE_DELAY_UNTIL_REBOOT and
lpNewFileName is NULL, MoveFileEx
registers the lpExistingFileName file
to be deleted when the system
restarts. If lpExistingFileName refers
to a directory, the system removes the
directory at restart only if the
directory is empty.