I need to have two processes running on Windows (7), where both of them will have different substitued drives, like:
subst P:\ C:\path1
...and the second one
subst P:\ C:\path2
(Why do I need it: Old project files (C++ Builder 5) have the paths to source codes and libraries specified like P:\,L:\,....etc ... and I need them to compile on a buildserver)
How Iam solving it right now:
creating net user temporaryuser
paexec/pstools login as temporary user, runing subst and then running the build
Is there any other (or better) solution?
-> Even making a systemwide hook that would respond with a substitued drive based on a process-id, is, for me, actually a better solution.
(What cannot be done:
-> C++ Builder 5 does not accept %variables% inside project files, so that is not an option.
-> Manually substituing drives in project files is dangerous, because the whole thing goes from git and then gets commited again)
Thank you!
Related
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?
I'm having issues with a few .ocx files in vb6. I have 2 components registered but when I attempted to add both into my project it says that I need to register them. I have tried copying new files into the sysWOW64 folders and still it does not work.
This occasionally happens when there is some corruption and conflict in the registry. One way to fix this is to place the two items in a folder within the project and add them by manually going to the reference and selecting that local copy, it will automatically register it as a new object and often (although not always) will fix the corruption by tagging the new path and it often resolves the issue you are facing. The only problem is that in the future projects, you may need to repeat the process or have access to the items.
The cleaner approach is to find all instances of the files on the system by doing an advanced search and finding ALL COPIES of them on the system, often they are all over the place. Once you have those paths, you need to regsvr32 /u <filepath.filename> each one to clean remove them from the registry and then place them in a common area and then register them from ONE location using regsvr32 <filepath.filename> and now things should work fairly cleanly.
Easiest way to find all instances on your machine (at least for me) is to simple go to your command prompt (if using more recent than XP, then as administrator) and then simply type:
C:
cd\
dir /s <filename.ext> > c:\files.txt
and wait until its done, at that point you open that file and it should give you all the paths to the files you need and you can easily turn the text file into a batch file by adding the commands you need to unreg and run it, voila, quick and fairly painless. If at anytime you unreg and it whines about it not being registered or can't do it, don't worry, just acknowledge and move on. Some OCX and DLL don't have registration entry points. If you register and it complains saying it can't do it, then you pretty much have no choice but to it the way I mentioned at the very beginning, by direct linking in your reference and having it drop into your project.
Final note, unless they are 64 bit compatible, you don't need and often shouldn't put them in the WOW system folder but rather system and system32 folders depending on version control and binary control of the original OCX.
I need to share my data and R source files with a coworker who doesn't have any experience with command line. Moreover, I work in Linux while she's under Windows. But she would like to change some constants and recalculate the scripts. So, it would be cool if she could just double click the R source file and R will be executing in the same directory where the source and data files lie. I thought about setting
Rscript -e "source(\"%1\",chdir=TRUE)"
to the association key in the registry, but the filename (%1) will contain backslashes which R will not handle.
Another way is to setwd() to the source directory in the beginning of my script, but I don't know how to obtain it. AFAIK, argv[0] will be R.exe, not the source.R.
Using GUI is not very convenient, either, because it requires to separately change directory and then to load the script.
Do I have to write a R loader (exe or cmd) for this?
A couple of hints, made as someone who works on Windows by day, and Mac OS by night. I create my projects in a Dropbox folder which is common to both machines. I follow this work practice.
I use RStudio on both my machines. I start up RStudio by right-clicking on the script file locally and this sets the working directory to the file being opened. If I then keep all paths in my script relative, then I can share my projects with myself easily :)
I start my scripts by setting a global variable, in a line that looks silly:
DIR <- getwd()
and then I use relative paths throughout the rest of the scripts. with lines like this:
new.path <- paste(DIR, "rel-path", "to", "new", "file", sep="/")
This avoids my having to tinker with profiles on each machine. It does look obvious, but it gives me one place to change the DIR value in case I want the script to point elsewhere, say, in the morning
DIR <- "~/workspace/newproject"
or, in the evening,
DIR <- "c:/R_workspace/yet/a/different/project"
I also have to be careful that I use the same R version and packages as, in a few cases, that has led to hiccups a few times.
It is a simple flow, but effective and allows seamless working across the two systems
Oops. Explorer starts R in the source directory if it is not on network folder. Initially I tried to start it on network folder. So the only thing to do is to copy the files to the local drive, or to map the network drive to a letter.
I have an automatic update system that replaces my existing program files on reboot. (Suffice to say, it's a very complicated program with many drivers, services, and user level modules. There really is no other way. Trust me.)
The function MoveFileEx is used with MOVEFILE_DELAY_UNTIL_REBOOT to setup this file replacement. I'm finding that it works just fine, normally. However, if the source and target files are on different drives, the target is deleted but the source is not moved. The result is that when the user installs the software on a drive different from the system partition, an update deletes the product file rather than update them.
Now, I see in the documentation for MoveFileEx that MOVEFILE_COPY_ALLOWED should be used when moving a file from one volume to another. But it also says that flag cannot be used with MOVEFILE_DELAY_UNTIL_REBOOT.
Q: How can I move a file on reboot, overwriting an existing file, when the source and the target are not on the same volume?
Why don't you just copy the files to the drive where the user installed your program?
As far as I see there is no direct way to do what you want relying only on this function.
Finding writable location on the same drive might be a problem on Vista, but you mention you have services - if they run with LocalSystem privilleges have them write the new files.
One other simple update mechanism that I have used ( not working for drivers though) is to have dedicated update program - kill/end everything, let the update program do its work and start everything up again.
In Win32, your main thread's current working directory is set to the location the executable was launched from. My problem is that even after a call to SetCurrentDirectory() to somewhere else, the process apparently still has a filesystem object referencing this initial startup directory (verifiable with a tool like Process Explorer) - which means this director cannot be deleted by the process.
Does anybody here know of a not-too-hacky solution? I'm specifically running into the problem with a program that integrates with explorer (adding a verb to HKCR\Directory\shell registry key), I need to process files in a right-clicked directory and the remove the source directory, which is impossible because the initial working directory is set to, you guessed it, the right-clicked directory.
EDIT: I'll go for the "use helper launch-from-sane-directory" approach. It might not be super elegant, but it will work and doesn't require any nasty hacks.
Your easiest solution may be to just spawn a little helper process that runs in whatever directory you specify (c:\, e.g.) and then just exit and let it do its thing. It may need to be synchronized with a mutex, or perhaps just retry two or three times on a timer...
I had another thought: You may be able to use CreateFile() with FILE_FLAG_DELETE_ON_CLOSE. Then it should go away when everyone lets go of it, but only if it was opened with FILE_SHARE_DELETE.