In Windows command prompt, how do I list out the latest created files in a system drive (e.g. C:)?
I would like to test a software that creates unknown temporary files in various places within the system drive, and like to know when each files is created during runtime, and want to make sure that the uninstallation does indeed remove these files.
My idea is to start the program, and repeatedly search in command prompt. Or is there a simpler way to track?
Related
Im trying to run several different scripts on my Mac for data stored in different paths. So I put all said scripts into a folder. In order for a script to work, I have to be cd'd to a specific folder required for said script. I use the scripts to get different types of output (ex: Image volumes, MRI info, etc..).
I was wondering if there was a way to store all my scripts in one directory and assign a shortcut to it. That way, I can cd to my folder, and only type something like $ScriptsFolder/Script_1 to have it. Ive seen this done in the FSL software package, where typing $FSLDIR/data/standard would give you the items in that folder.
UPDATE:
Im using Script=/Users/ray/Documents/Script which works until I close down my terminal to start a new one. Any way to make the setup permanent?
EDITED
Found this helpful in the end.
http://www.techradar.com/how-to/computing/apple/terminal-101-creating-aliases-for-commands-1305638
I used it to create a shortcut to my scripts which are all placed in a folder for easy referencing.
I have written my own screensaver, which makes use of additional files located at the same directory as the screensaver executable (.scr file).
If I right-click on the screensaver and select 'Test', all is well, those extra files are found.
But if I right-click and click on 'Install' to install the screensaver, it seems to not be able to find those files anymore.
Does the installation process make another copy of screensaver, or maybe change the working directory? If so, what directory is it in?
It's a Windows 7 desktop.
So far I have searched in Windows folder, Program Files, Program Files (x86).
UPDATE:
So, I added the following bit of code to determine the executable's location.
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName
It appears that the screensaver is running from the directory where I put it, from the original file. However, after installing it, the only way I can reach files in the same folder from the executable is if I use full paths. If I run it as Test, I can simply use filenames only.
This should be a clue as to what is going on, I think. The above function, if I run it as Test, returns long file names, but if I run it as Installed, it returns short file names. I think that when Installed, it runs as some kind of a special process, or maybe a child process, which also interferes with file access.
What is going on?
I added a piece of code to determine the current working directory, and found that when running the screensaver in Installed mode, the current working directory becomes C:\Windows\system32, which would of course explain how files are referenced.
Environment.CurrentDirectory
I am trying to keep two directories synchronized with the same files in them.
Files are dropped into Directory A throughout the day. I would like to create a file watcher script that will copy files from Directory A to Directory B as soon as they are dropped.
My thought was to run the job every minute and simply copy everything that dropped in the last minute, but I am wondering if there is a better solution out there.
I'm running MKS toolkit under Windows. Different servers, same operating system.
Thanks for your help!
If you use Linux, you can hook into the kernel using the inotify API to get notified if something in a folder changes. There are command line versions like inotifywatch(1) as well.
To copy the files, I suggest to use rsync(1): it is clever, knows how to clean up after itself and it will create new files hidden while they are copied so users and programs are less likely to pick them up before they are complete.
I have a Ruby application I'm installing (along with a packaged ruby interpreter) under Program Files on Windows 7 with an NSIS-built installer. In order to debug it, I edited one of the files to add some debugging statements. After that, I uninstalled the package and ran a new version of the installer which includes a new copy of the edited file, without debugging statements.
Now, I can't get the new copy to load into ruby. If I run type <filename> in cmd.exe, or open the file in Notepad.exe or Firefox, I see the new version. If I run ruby -e "puts File.read('<filename>')", or open the file in emacs, I see the old version.
If, in Windows Explorer, I copy the file to a new filename, everything can see the new contents at that filename. If I delete the original file and rename the copy to replace the original, the split personality returns.
This situation survives a reboot, so it's not a simple matter of a file being accidentally held open.
What on earth is going on here? Is there some aspect of the install process that might be checkpointing the file in a way I can revert, or at least switch off while I'm debugging the installer?
update
If I run ruby -e "puts File.read('<filename>')" in a console that is run as administrator, I see the correct, new contents. How should I be managing this file?
I think it has to do with UAC file system virtualization. Check whether your file exists in C:\Users\<username>\AppData\Local\VirtualStore. If it does, delete it from the VirtualStore.
The fact you see the correct file when running Administrator console proves that it's because of virtualization: UAC virtualization is turned off for elevated processes.
In general, do not put files you plan to change a lot in Program Files. From Vista onward, there is an interesting way things work to "allow" you to write to a protected file, but it really gets stored in your app data directories, not actually in Program Files. So, utilities that go through the Windows API find the "new" version of the file correctly, but utilities that are more low-level (ruby.exe) only find the existing version. If you navigate to that folder, do you see a "Compatibility Files" button right above the contents? Press that and you'll see your updated version.
Scott Hanselman wrote a good article about this when it was introduced in Vista.
You can only write to the real file when you're logged on as Administrator.
My installer requires there be two files in the same directory in order for it to install.
The installer (.msi file)
An organization specific config file that the installer copies. (This file is customized by the organization and then distributed to it's end users).
Since there are two files, the file has to be distributed as a zip file. Which presents the issue of if a user tries running the .msi without actually extracting the zip... only the msi file gets extracted. I am able to detect the issue in the install process and tell the user they need to unzip the file... but you know how noone actually reads error messages.
So, I'd like to make it more foolproof and so i was wondering if there was a simple tool that i could let my customers (ie the organization) be able to make modifications to the config file and when finished create a .exe file which when clicked would extract to a temp folder and then run the msi. I know there are solutions for this which require commercial software. I'm wondering if a simple freeware tool exists that can do this.
Edit: Accepted Solution Notes:
The one issue i ran into is the iexpress wasn't designed to be used for .msi files. As a result on the step that asks you for the Install Program. It's a combo box which if you had added a .exe file in the previous step could just select the .exe file from. Instead you have to manually type in
msiexec /i yourinstaller.msi
I was very pleased to find such a simple solution that's built in to windows. The only way this could be better is if it allowed for wildcards so that your iexpress project would be able to handle changes in the msi file's name which occur with each version. And defaulting the Install Program to the .msi file. These minor inconveniences are offset by the fact that end user wouldn't need to install any new software to create the package so I have stopped looking for other tools.
You could try using iexpress.
It enables you to package up a set of files which can be extracted, with the option of running an installation command automatically after extraction. It also has options to enable you to prompt users about things, show a EULA, restart the computer, etc..
I believe it comes as part of Windows (part of IE?) - try running iexpress.exe from the run dialog to get the UI.
The Wix project has a bootstrapper and packager for dealing with this kind of thing.
I've used wix a lot but haven't really looked at the bootstrapper/packager much - last time I had a quick look it wasn't really usable but that was a long time ago so it may be better now.
I'm guessing that the config file is something like a properties file, and that you want users to set the values of the properties "foo" and "bar". You don't need a separate tool to update the file.
I would do this:
Put one or more dialogs in the install that ask the user what the values of foo and bar should be, and set a couple public properties accordingly.
Write a custom action that writes the config file out to whatever location you want, including whatever values you want for foo and bar. This would be pretty easy in vbscript.
Put the custom action somewhere in the execute sequence (ideally as a deferred execution action, since you're making changes to the system).
Add an entry to the RemoveFile table, so the config file is removed on uninstall (assuming you don't want it to be left behind.)
Add an entry to the LaunchCondition table, to prevent users from doing a silent install. Or if you want silent install to be allowed, make the names of the public properties that hold the config data known, and make them part of the LaunchCondition. You would block "msiexec /i myapp.msi", but you could choose to allow "msiexec /i myapp.msi FOO=Something BAR=SomethingElse".