I need to add version info and retrieve it from the CHM file to make it possible to make an alert message to a user about a new CHM-file version available and downloaded.
It means, that I should compare versions of CHM on different machines (Server and clients).
The other way is date and time checking, but I should remember about time zones, so this is complicated, because also one should remember about different file systems, according to Windows SDK help about SetFileTime function and FILETIME structure.
If someone knows the trick - please share.
.chm files don't have version information. You will need to find some alternative way to mark the file version.
One way that occurs to me is to include a topic in the help file that contains the version. I imagine that this topic would be hidden, that is not linked by any other topic, not in the table of contents, etc.
All that remains is for your application to be able to read that topic from the help file. I'm sure that can be done with a .chm file parser, if you can obtain one. Perhaps more easily you can get the platform browser to read the topic for you. You can use IHTMLDocument2 to read a URI like this:
mk:#MSITStore:C:\somedir\somefile.chm::/html/SomeTopic.html
Related
According to the documentation, the fourth parameter of FSEventStreamCreate (a function used to receive events about file changes) is "A CFArray of CFStringRefs, each specifying a path to a directory, ..." but I'm interested in changes to a specific file only. I know that I can pass the directory the file is in and then filter the events, which is what I've been doing up until now, but I have found out, that if I simply pass the file's entire path, it works perfectly fine (and allows me to simplify my code significantly).
So my question is, since I want to put this into production software, is this something I can rely on to work (e.g. in other versions of the OS), or is it a fluke? Is it documented somewhere to work this way? Does anyone else use it this way? My best guess is that the documentation is phrased like this because by default, only filesystem changes are reported, and the flag kFSEventStreamCreateFlagFileEvents has to be added to make it also report file content changes, but maybe I'm wrong.
The only thing Apple says about this is here
Request file-level notifications. Your stream will receive events about individual files in the hierarchy you're watching instead of only receiving directory level notifications.
Regarding other developers using this feature: yes, there are some.
You can probably leave a feedback on Apple, asking to improve the documentation, and maybe one day they will.
I’m new to the IT industry but keen to learn.
Wanted to ask if anyone could point me in the right direction when trying to create a Powershell script to change settings within a computer app called plantronics hub.
Just need a better insight to what commands I need to use and functions. Just so that instead of going to a users machine every time and changing the settings I can just run a script and let it do it for me.
There are a few things you can look at. Look through the program files to see if there's any kind of command line utility for this sort of thing. Obviously, documentation is another good place to look. If available, you can also call their support and simply ask. Keep in mind they may have already considered this scenario, and may have other suggestions.
Try and figure out how the application stores its settings, Registry, XML, ini file etc...? PowerShell can work with any of these, but you need to answer this question before knowing what direction to go it.
If the settings are in the registry I'd start looking under HKLM:/ & HKCU:\Software\Plantronics. Settings and/or configuration files may be in the program files folder or under the user profile app data folders.
A few techniques:
Export the registry, make a configuration change, export the registry again to a different file. Compare the 2 files via some file comparison tool, like BeyondCompare or WinMerge. This might help you find anything that changed after you made the change.
Use procmon.exe . If you filter it properly you can determine which files the application is touching either on start or when you make a configuration change. ProcMon can also help identify which registry keys and values are being looked at.
Note: If the settings are consistent between stations you may be able to copy the config. This could be as simple as a file copy or importing a registry file.
I built a very simple minifilter driver as part of a lesson on minifilters. I've also read the minifilter documentation that Microsoft provides which is in the form of a PDF doc, as well as this reference. These guides explain how to set up a context and an instance. However, they do not explain why one would use a context and/or instance and what they are for. My very small filter driver used NULL for both context and instance and still operates, so I am wondering the use-case for these constructs.
There are many reasons why you would want to use contexts for files, volumes etc.. Certainly filters and even file-systems could operate without them, but the performance would be really bad.
Imagine this scenario: you are an AV (AntiVirus) and want to scan some files to check if they contain malicious code or not.
You register your minifilter and callbacks and now you are being called and you need to make a decision on a file as it is opened.
There are a few steps involved:
You query the file name and security context
You read the file contents
Alternatively hash the file with a SHA256 to see if it matches in your AV database for example
You check if the file is digitally signed, also part of your check
You parse the file's PE header if it has one to see what kind of file or executable it is to help you in your decision
You apply your policy on the file based on all the information above
Now let's assume the file is clean and goes away. If you cannot hold on to the information that you just learnt about the file, the next time the file is opened you will have to re-do it all over again. Your performance will suck, and your OS will crash and burn slowly to the ground.
This is where contexts come in handy.
Now that you have all this information about the file, you store all of it in your context that is then associated with this file. Next time you see the file you simply query its context and have all the information you need.
Of course some things will need to be updated, for example if you notice the file has been changed then you mark it as dirty and update as needed on the next Create or Cleanup callback.
Alternatively you could use a cache, where after the file is closed for good and the minifilter wants to free the context you have associated with the file you can save it yourself.
Now, the next time the file is opened you look for the context of the file ( NTFS support unique file ids for files ) and just associated it with your file and know immediately everything you need to know about that file
This is only one usage, but now you can think for yourself of many more scenarios where they are useful.
I would like to upload documents to GoogleDocs every time the OS hears that a file was added/dragged/saved in a designated folder, just the way DropBox uploads a file when you save it in the DropBox folder.
What would this take in Ruby, what are the parts?
How do you listen for when a File is Saved?
How do you listen for when a File is added to a Folder?
I understand how to use the GoogleDocs API and upload things once I get these events, but I'm not sure how this would work.
Update
While I still don't know how to check if a file is added to a directory, listening for when a file is saved is now dirt simple, thanks to Guard for ruby.
If I were faced with this, I would use something like git or bzr to handle the version checking and just call add then commit from your script and monitor which files have changed (and therefore need to be uploaded).
This adds the benefit of full version control over files and it's mostly cross platform (if you include binaries for each platform).
Note this doesn't handle your listening problem, just what you do when you know something has changed. You could schedule the task (via various routes) but I still like the idea of a proper VCS under the hood.
I just found this: http://www.codeforpeople.com/lib/ruby/dirwatch/
You'd need to read over it as I can't vouch for its efficiency or reliability. It appears to use SQLite, so it might be better just to manually check once every 10 seconds (or something along those lines).
Ruby doesn't include a built-in way to "listen" for updates to files. If you want to stick to pure Ruby, your best bet would be to perform the upload on a fixed schedule (say every 5 minutes) regardless of when the file is saved.
If this isn't an acceptable alternative, you could try writing the app (or at least certain parts of it) in Java, which does support this type of thing. Take a look at JRuby for integrating the Ruby and Java portions of your app.
Here is a pure ruby gem:
http://github.com/TwP/directory_watcher
I don't know the correct way of doing this, but a simple hack would be to have a script running in the background which checks the contents of a bunch of folders every n minutes and uses the associated timestamps to determine if the file was modified in that span of time
You would definitely need some native OS code here, to write the monitoring service/client. I'd select C++ if you want it to be cross platform. If you decide to go with .Net, for example, you can use the FileSystemWatcher class to achieve what you need (documentation and here's a related article).
Kind of an old thread, but I am faced with doing something similar and wanted to throw in my thoughts. The route I'm going is to have a ruby script that watches a given directory and checks the timestamps. Once all files have been uploaded, the script saves the latest timestamp and then polls the directory again, checking if any files/folders have been added. If files are found, then the script uploads them and updates the global timestamp, etc...
The downside is that setting up a ruby script to run continually (or as a service) is somewhat painful. But it's not an overwhelming task, just needs to be thought out properly.
Also depends on if your users are competent enough to have ruby installed or if you have to package everything up into a one-click installer as well. That, to me, is the hardest part to figure out.
My windows co-workers were asking me if I could modify my non-windows binary files such that when their "Properties" are examined under Windows, they could see a "Version" tab like that which would show for a Visual Studio compiled exe.
Specifically, I have some gzipped binary files and was wondering if I could modify them to satisfy this demand. If there's a better way, that would be fine, too.
Is there a way I could make my binaries appear to be exe files?
I tried simply appending the VS_VERSION_INFO block from notepad.exe to the end of one of my binaries in the hope that Windows scans for the block, but it didn't work.
I tried editing the other information regarding Author, Subject, Revision, etc. That doesn't modify the file, it just creates another data fork(what's the windows term?) for the file in NTFS.
It is not supported by windows, since each file type has their own file format. But that doesn't mean you can't accomplish it. The resources stored inside dlls and exes are part of the file format.
Display to the user:
If you wanted this information to be displayed to the user, this would probably be best accomplished with using a property page shell extension. You would create a similar looking page, but it wouldn't be using the exact same page. There is a really good multi part tutorial on shell extensions, including property pages starting with that link.
Where to actually store the resource:
Instead of appending a block to the file, you could store the resource into a separate alternate data stream on the same file. This would leave the original file stream non corrupted on disk and not cause its primary file size to change.
Alternate data streams allow more than one data stream to be associated with a filename. Each stream is identified by a colon : at the end of the filename and an identifier.
You can create them for example by doing:
notepad test.txt:adsname1
notepad test.txt:adsname2
notepad test.txt
Getting the normal Win32 APIs working:
If you wanted the normal API to work, you'd have to intercept the Win32 APIs: LoadLibraryEx, FindResource, LoadResource and LockResource. This is probably not worth the trouble though since you are already creating your own property page.
Can't think of any way to do this short of a shell extension. The approach I've taken in the past is a separate "census" program that knows how to read version information from any kind of file.
Zip files can be converted into exe files by using a program that turns a zip file into a self-extracting zip (I know that WinZip does this, there are most likely free utilities for this also; here's one that came up on a search but I haven't actually tried it). Once you've got an exe, you should be able to use a tool like Resource Hacker to change the version information.
It won't work. Either Windows would have to know every file format or no file format would be disturbed if version information were appended to it.
No, resource section is only expected inside PE (portable executable; exe, dll, sys).
It is more then just putting the data inside the file, you have a table that points to the data in the file header.
What you can do if you have NTFS drive, is to use NTFS stream to store custom properties this way the contact of the binary file will remain the same, but you will need to use a custom shell extension to show the content of the stream.