I am trying to develop an application for monitoring operations on a particular folder which includes creating, deleting, modifying, moveing, duplicating and renaming.
After referring to the FileSystemWatcher API, I found that it does not provide a Move event, instead it will generate a separate Delete and Create events for the same file. Of course I can wait for a Create event each time a Delete event is detected and decide whether it is a Move event or not, but it is a little bit strange to me and the appropriate time to wait for is also a problem.
Actually I find that Dropbox is able to detect the Move event correctly even when dropbox process is not running. Nice work for Dropbox team and I wonder how do they make it work on earth.
So my purpose is quite clear : Filtering Move event from other events and making it work offline (which means when the procedure is stopped)
Well, a move operation is basically a "copy & delete" from the FileSystemWatcher's point of view. Without knowing details about the implementation I bet DropBox stores a hash for each file. If a file is removed in one place and created with the same hash in another place, chances are it was moved. You could actually do the same thing.
Related
The Microsoft Documentation reads:
Notification icons specified with a GUID are protected against spoofing by validating that only a single application registers them. This registration is performed the first time you call Shell_NotifyIcon(NIM_ADD, ...) and the full path name of the calling application is stored. If you later move your binary file to a different location, the system will not allow the icon to be added again. Please see Shell_NotifyIcon for more information.
Since the documentation on Shell_NotificyIcon is rather sparse on how to unregister the GUID again, the following question arises: How do I properly remove the NotificationIcon again when I uninstall the corresponding app again?
There is the brute force approach which is described here, which deletes all system icons and the process explorer.exe must be restarted again. However I'm wondering if there exists more punctual approach.
Another option would be to just create a new GUID, every time a user installs the application or moves it to a new location. Is this considered best practice?
10 year old answer from a Microsoft employee speaks of a possible workaround when changing the path and at the same time claims there is no way to unregister:
There is no way provided to unregister that. If your binaries are Authenticode signed then the registration can move with the application. See the Troubleshooting section in the NOTIFYICONDATA documentation.
Note The only exception to a moved file occurs when both the original and moved binary files are Authenticode-signed by the same company. In that case, settings are preserved through the move.
Both binaries would need to be present simultaneously when the icon is created for the path to be updated.
I personally never use a GUID, I just use the classic ID mode from Win95.
When creating an uninstaller for a Windows app, should I remove an event source?
I'm not looking for a philosophical discussion, I'm looking for specific technical reasons why it may or may not be a good idea to remove an event source, esp. given that events written to that source will be left behind.
Good:
Regarding to manifest-based event generation, it may be good idea to leave the source in the system so other event consumers can properly render messages generated by the source after the program is removed.
Bad:
Orphan event sources choke up the system registry.
It is impossible to create new event source with the same name even in different channels. Hence, you will have to somehow manage conflict situations on re-install.
I have a bunch of files that I download at some point and then customize. I want to keep the originals, but also allow modifications, and I want to do this using hard links.
I figure I first download the batch of files into some sort of repository, then create hard links into my work location. I want to let the user delete his files (e.g. delete the hard link), which doesn't pose problems.
However I also want to let him write to them, in which case I want my original file to be left untouched in the repository, so I can revert later. How can I do this transparently, without actually locking the file and forcing him to delete it and recreate it?
Any ideas greatly appreciated, thanks.
Cosmin
In windows you have no such option as NTFS/FAT doesn't support snapshots. Hard links are just links anyway, both point to a single file and if link A is changed link B is changed also.
You can partially achive the same result with Windows File History however I don't know any way to set it up exaclty as you described.
I have written an application that uses Isolated storage store data that I want to clear out on a periodic basis when it gets old. I have written a function that is called from Closing that checks the isolated storage for old data and deletes it.
This routine will delete everyfile that it is supose too except the last two files in the directory. When I debug the code I can see it execute the DeleteFile method on those files. I even when as far as checking right after the call to DeleteFile to see if the file still exists. According to the debugger it does not.
Yet when the appication starts up again the old data is for those last files is still in isolated storage. Thinking that it may be a race condition I put a Thread.sleep(1000) after the delete routeines.
The phone does not honor this delay and exits immediately after executing the delte code. I could not find a flush command that would be related to DeleteFile as I don't have a reference to a stream at that point.
Has anyone else found this or something similar? Is there a magic flush method I am missing or is this a defect in the phone IsolatedStorage implementation?
i agree with Matt and Matthieu.
though also wish to ask u have u tried truncating the file?
IsolatedStorageFileStream isfStream = new IsolatedStorageFileStream(strXMLFile, FileMode.Truncate, isf);
Like many programmers, I'm prone to periodic fits of "inspiration" wherein I will suddenly See The Light and perform major surgery on my code. Typically, this works out well, but there are times when I discover later that — due to lack of sleep/caffeine or simply an imperfect understanding of the problem — I've done something very foolish.
When this happens, the next step is do reverse the damage. Most easily, this means the undo stack in my editor… unless I closed the file at some point. Version control is next, but if I made changes between my most recent commit (I habitually don't commit code which breaks the build) and the moment of inspiration, they are lost. It wasn't in the repository, so the code never existed.
I'd like set up my work environment in such a way that I needn't worry about this, but I've never come up with a completely satisfactory solution. Ideally:
A new, recoverable version would be created every time I save a file.
Those "auto-saved" versions won't clutter the main repository. (The vast majority of them would be completely useless; I hit Ctrl-S several times a minute.)
The "auto-saved" versions must reside locally so that I can browse through them very quickly. A repository with a 3-second turnaround simply won't do when trying to scan quickly through hundreds of revisions.
Options I've considered:
Just commit to the main repository before making a big change, even if the code may be broken. Cons: when "inspired", I generally don't have the presence of mind for this; breaks the build.
A locally-hosted Subversion repository with auto-versioning enabled, mounted as a "Web Folder". Cons: doesn't play well with working copies of other repositories; mounting proper WebDAV folders in Windows is painful at best.
As with the previous method, but using a branch in the main repository instead and merging to trunk whenever I would normally manually commit. Cons: not all hosted repositories can have auto-versioning enabled; doesn't meet points 2 and 3 above; can't safely reverse-merge from trunk to branch.
Switch to a DVCS and "combine" all my little commits when pushing. Cons: I don't know the first thing about DVCSes; sometimes Subversion is the only tool available; I don't know how to meet point 1 above.
Store working copy on a versioned file system. Cons: do these exist for Windows? If so, Google has failed to show me the way.
Does anyone know of a tool or combination of tools that will let me get what I want? Or have I set myself up with contradictory requirements? (Which I rather strongly suspect.)
Update: After more closely examining the tools I already use (sigh), it turns out that my text editor has a very nice multi-backup feature which meets my needs almost perfectly. It not only has an option for storing all backups in a "hidden" folder (which can then be added to global ignores for VCSes), but allows browsing and even diffing against backups right in the editor.
Problem solved. Thanks for the advice, folks!
Distributed Version Control. (mercurial, git, etc...)
The gist of the story is that there are no checkouts, only clones of a repository.
Your commits are visible only to you until you push it back into the main branch.
Want to do radical experimental change? Clone the repository, do tons of commits on your computer. If it works out, push it back; if not, then just rollback or trash the repo.
Most editors store the last version of your file before the save to a backup file. You could customize that process to append a revision number instead of the normal tilde. You'd then have a copy of the file every time you saved. If that would eat up too much disk space, you could opt for creating diffs for each change and customizing your editor to sequentially apply patches until you get to the revision you want.
if you use Windows Vista, 7 or Windows Server 2003 or newer you could use Shadow Copy. Basically the properties window for your files will have a new tab 'previous version' that keeps track of the previous version of the file.
the service should automatically generate the snapshot, but just to be safe you can run the following command right after your moment of "inspiration"
'vssadmin create shadow /for=c:\My Project\'
it has defiantly saved my ass quite a few times.
Shadow Copy
I think it is time to switch editors. Emacs has a variable version-control, which determines whether Emacs will automatically create multiple backups for a file when saving it, naming them foo.~1~, foo.~2~ etc. Additional variables determine how many backup copies to keep.