So let's imagine we have a "c:\1.txt" text file,
and a folder "c:\other\" that contains 3 other text files (A, B, C).
What I want to do is, redirect c:\1.txt to A, B, or C randomly, or according to a specific time of day.
For example, if you open the 1.txt file, with any application (notepad, wordpad, whatever).. Windows should act like it's talking to "c:\other\A.txt" for readings, writings, etc.. instead of c:\1.txt. As if Windows is lying to all other applications and acting like the file changed, when it's actually just redirecting to an other file, and not changing the real one.
Windows 7 already does something like this with the 'program files' folder I think, but I need to be able to switch files (between A, B, C) using Windows API or something, with Java, or any other common programming langage. I need to tell Windows what file to choose each time.
Has anyone ever heard of something like this before? Is it possible? How?
You can do this with a symbolic link. At the command line you would do it like this:
C:\>mklink 1.txt other\A.txt
symbolic link created for 1.txt > other\A.txt
Programmatically you use the CreateSymbolicLink function.
But you cannot do that and keep a true file named C:\1.txt. You cannot have two distinct objects with the same name.
Regarding the Program Files and Program Files (x86) folders, they are just ordinary folders. It's only convention that says that 64 bit apps go in the former, and 32 bit apps go in the latter. Perhaps you are thinking of the file system redirector which affects the system32 folder. Anyway, that's really outwith the question.
Related
I've created a simply toolbox/dashboard in Visual Studio Express in VB for my work that contains links to all of the software and shortcuts we use on a day-to-day basis (see the image below, company name/app names covered to protect the innocent :p)
This was originally created for just me, then I modified the code to work on my co-workers computer. The changes that needed modifying were the addresses for each of the apps. Say, for example, App 1 is directly on the C:\ drive for me, but for my co-worker it is buried in C:\Program Files\blah blah blah. I would have to go in and hard code that path for each and every differing app path, and then if something happens and the path changes, I have to recode it again before deploying it.
What I would like to do it something where the user can modify the path so all I have to do is deploy the executable and the user can modify the path on their own. What would be the best way to accomplish this? Would it be best to have the executable look for a text file to read from/write to? Is there an easier and more effective way to do this? I'm open to any suggestions at this point
If you shellexecute just the program name, it will be looked up in the AppPaths registry key. See HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths. Plus it will open anything. If you want to open a text file a.txt, register it as a.exe. Typing a will run the command (notepad c:\somewhere\a.txt).
My company ships a package containing several Qt-based MacOS/X GUI applications; the package ships as a .dmg file, and "installation" consists of double-clicking the .dmg icon, then dragging one or more application icons to where he wants to keep them (e.g. to his own Applications folder).
This works fine, but the .dmg file is rather large (e.g. 40+MB) and I'd like to reduce its size if possible, in order to reduce the time it takes to download it. One thing I notice is that the applications in the package all have a significant number of large files in common (Qt libraries, graphic resource files, etc), and that currently we are including a separate copy of each of these files inside the blah.app/Contents folder of each included application -- presumably this is what makes the .dmg file so large.
So my question is, is there any way to modify the .dmg so that it doesn't need to include several copies of these files, and thus isn't so big? Ideally I'd like to do this without requiring the user to run a special installer program, and without causing any of the applications to break if the user moves them to different (or unexpected) folders, or deletes any of them.
It seems like this would be an ideal application for hard-links -- i.e. prepare the input to the .dmg file such that one application contains the actual files, and the other applications contain hard-links to those files, so that after the user unpacks the applications from the .dmg file the files remain logically independent of each other (and in particular application B won't stop working if the user moves or deletes application A). But AFAICT MacOS/X doesn't support hard-links [edit: to directories] for applications that aren't named Time Machine. :^(
(it feels vaguely immoral to answer my own question, but since I came to a solution I'll do it anyway, rather than leave the question hanging open)
The solution is to replace the duplicate files with hard-links to the first-encountered file, before running hdiutil to create the .dmg file. I did this using a simple C++ program that I wrote for the purpose (just because I'm stubborn that way), but there are also a number of freeware programs such as freedup that will do this for you. I didn't try them, but I imagine they all work fine.
I have an old program that saves its files to Program Files. We are updating it to run properly on Windows 7. The problem is that we now can't find our saved files. Windows 7 allowed our program to save to program files, but obviously put the files somewhere else. We can't find that 'somewhere else'. Does anybody know where Windows 7 places its files when we save in Program Files?
Update:
We've looked in program files, in program files (x86), we've used Windows Explorer search function to try and find the directory name. Nothing works, but when we check to see if the directory we are making already exists in our application, we find it and put up our error dialog box.
Look in C:\Users\[USERNAME]\AppData\Local\VirtualStore\Program Files\[APPNAME]
Possibly program files (86) if your application is a 32 bit app. The place they should be saved is in the users directory though (or even better, give the user the choice of where to save).
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.
Is there a way in Windows 7 to create a directory that has as its virtual contents all the files and folders from 2 other actual directories?
I'm hoping I can define a single dir that reflects the contents of 2 other dirs via symblinks or something without having to copy files.
*edit: I need to be able to specify the combining dir as a filepath. Looks like using a library doesn't let me do this.
c:\actualdir1\ a,b
c:\actualdir2\ c,d
c:\virtualdir\ a,b,c,d
thanks
Seems like libraries would be perfect for this. You can create a library and add folders to it from code, then use the library almost anywhere you would use a folder. You don't mention what language you want to use - for managed code the Windows API Code Pack has some wrappers for the shell stuff, and from C++ you can use shell APIs.
(If you're asking as a user then the answer is still libraries, but the question is offtopic and belongs on SuperUser.)
No, I don't think this is possible without writing your own Shell Extension. However, depending on what you are looking for, perhaps using Windows 7 Libraries would do the trick.