I recently followed a small tutorial on howto install apache on a systems where you're not the admin. Basically, the original htdocs and conf folders were copied to a map I have ownership over, the original ones deleted and then symbolic links were created.
Now, I checked mklink /? and it gives several options.
Directory symbolic link
Hard Link
Directory junction
Microsoft technet doesn't offer much explanation as to what the last 2 options really do.
So I'm wondering if there's someone here who can tell me what these options do and perhaps give an example of a situation where this is really usefull.
See the documentation on MSDN on Hardlinks and Junctions. It says:
A hard link is the file system
representation of a file by which more
than one path references a single file
in the same volume.
And:
A junction (also called a soft link)
differs from a hard link in that the
storage objects it references are
separate directories, and a junction
can link directories located on
different local volumes on the same
computer. Otherwise, junctions operate
identically to hard links.
Related
I know this is a noob question but I couldn't find a good explanation...
I am currently learning how to work with makefiles and I get sometimes an error like: 'STAGING_DIR not set' when running make.
I know I can export a directory as staging dir and the warning will go away but what is the meaning of it? and what make do with it?
If it is in any documentation a link will be more then enough thanks :)
There is no meaning for STAGING_DIR built into make, but the name STAGING_DIR suggests the designer of the makefile intended it to be the name of a directory where some sort of intermediate files would be put.
Most likely you can assign to it the path of any directory you create where files built during the build may be placed. However, inspect of the makefile would be necessary to determine how it is used. If it is used solely for intermediate files, and not permanent files, then you can use a temporary directory and remove it when you are done building, or you might use a semi-permanent directory with the benefit of faster builds when you build incrementally. (What constitutes a temporary or semi-permanent directory is mostly a matter of convenience: You might put a temporary directory in a common path used for such things, hopefully on a disk volume with available space and good performance, possibly a directory pointed to by $TMPDIR. Some areas designated for temporary directories may be automatically cleaned up by the operating system at times. You might put a semi-permanent directory somewhere in your own home directory and remove it at your convenience.)
In spite of the name, STAGING_DIR might be used for final output files of the build, in which case using a temporary directory that is removed frequently might not be suitable. Again, inspect of the makefile is necessary to see how it is used.
MSI database contains set of tables, and I can successfully enumerate File table, which has all deployable file' meta-deta. What I need to extract is the actual contents of those files. msiexec, lessmsi, 7-zip all can do it, but I couldn't find any source/API to do it.
What I've discovered it that all other (resource) files are in Binary table, and Data field can be used to get content of those files (like icons, custom DLL etc).
Further, I found and know that Media table contains information about the .CAB file (MSI has all content embedded with <MediaTemplate EmbedCab="yes"/>. This simply means the CAB file contains the actual content. I probably need to read contents from "Structured Storage" of the .msi file.
How to extract the contents of CAB/MSI file, using native C Msi* functions?
Phil has given you the easy/simple answer but I thought I might give you a little more information since you've done some research. Checkout:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372919(v=vs.85).aspx
This is where the structured storage is. You'll see something like Disk1.cab as the Name (PK) and binary data. The data is a CAB file with the file entry in the cab matching the File.File column. From there you can use the File.FileName column to get the short name and long name (you'll want the long name no doubt) and do a joint to the Component table to get the directory table ID.
You'll also need to recurse the directory table to build the tree of directories and know where to put the files.
Fun stuff. There's some libraries in C# that make this WAY simpler. Or just call msiexec /a as Phil says. :)
The most straightforward to extract all the files to some location is to install the product in "advertised" mode. If you do a:
msiexec /a [path to msi] TARGETDIR=[some folder]
you'll see what happens.
In C++ call MsiInstallProduct () with that command line.
You have gotten many good answers already, including the use of dark.exe from the WiX toolkit. By downloading the WiX source code you should be able to get the code you need ready-made from there. I assume you may already have done this.
Chris has already linked to the DTF code you can check, but here is a link directly to dark.exe as well: https://github.com/wixtoolset/wix3/tree/develop/src/tools/dark. I would try both. This is C#, you seem to want native.
UPDATE: Before I get to the Win32 features you can use, check out this little summary of the C# DTF features: How to programmatically read the properties inside an MSI file?
Native Win32 functions: The database functions to deal with an MSI file can be found on MSDN (this is to deal with the MSI file as a database). There are also MSI Installer Functions (used to deal with the MSI file as an actual installer).
You can certainly find good examples of native code for this with a good Google search. Have fun!
BTW: It would help with a description of the actual problem you are trying to solve as well as what you need technically. There could - as always - be less involved ways to achieve what you need. Unless you are writing a security software or malware scanner or something super-involved.
And so it is clear: WiX's dark.exe fully decompiles MSI files into WiX source files and the resource files used to build them - you can then text and binary compare the various types of content (text compare for tables, binary compare for binaries, etc...). The process to do so via command line is described in the following answer: How can I compare the content of two (or more) MSI files? (this is about comparing MSI files, but one option to do so is to decompile them - see section on dark.exe - just for reference for others who find your question).
I like to link things together so we can find content easily at a later point in time. Strictly speaking it doesn't seem necessary here, you have what you need I think but others could perhaps benefit from some further links. Here are some related links:
Extract MSI from EXE.
What is the purpose of administrative installation initiated using msiexec /a?
How do I extract files from an MSI package? (explains why you should not use 7-Zip to extract).
I'm having a tough time with ClearCase. I'm working with a dynamic view.
Somehow, I got two files that are eclipsed. I compared the folder in my version (with the eclipsed files) with every version on my branch and every version on the main branch. The original files are nowhere to be found.
I searched for the files in Windows Explorer and found them in the lost+found directory (with a 32 character extension). This directory appears to be invisible because I can't see it in either Windows Explorer or ClearCase.
I opened a DOS window and ran cleartool. I removed the files (I had fun typing it all, plus the 32 character extension at the DOS prompt). I could not find a way to delete them from either Clearcase Home Base or ClearCase Explorer.
I thought this would solve my problem, since there are no more files with the same names anywhere on my computer.
I deleted the eclipsed files and created them again in Qt Creator. But when I opened ClearCase Explorer again, there they were - eclipsed! I cannot figure out where the evil twins are. I tried finding the eclipsed files by using cleartool. Nothing. I've tried many approaches I've found online - none work.
I tried stopping and starting the view. I deleted the eclipsed files again, closed Qt Creator and then opened Qt Creator again and recreated them. I tried many other things suggested - none made any difference.
If I'm eclipsing existing files, where are they? I'm starting to think that the real evil one here is the parent - ClearCase!
Eclipsed doesn't mean evil twins (the fact that you add multiple times a file does though).
When you add to source control a file, ClearCase will:
checkout the parent directory
access the file in order to create a temporary one (called 'afile.mkelem')
create the file in the ClearCase vob
check in the parent directory
I usually see repeated eclipsed file when ClearCase isn't able to access the content of a file, because another process prevents it.
Try adding those files after closing the Qt editor.
The OP Rob Moore mentions having solved the issue with:
I changed the view to main/LATEST, and the file showed up.
I went to the tree view of that file and noticed that I had a branch there with one version.
I compared my branch version with the main/LATEST and they were the same, so I deleted my branch and put my label on the main/LATEST version
So it is possible that, as soon as the element was added, it wasn't properly selected by the config spec (being a new version on a branch which wasn't part of the config spec), and its state reverted to "eclipsed".
what is symbolic link in solr. Is there any concept exist in solr related to schema..?
Is it related creation of class object specified in schema.xml.. ?
Symbolic link is a concept in computing not in Solr.
In computing, a symbolic link (also symlink or soft link) is a special
type of file that contains a reference to another file or directory in
the form of an absolute or relative path and that affects pathname
resolution.
One of the exaple when you need symbolic link is, if you install solr using package manager then it installs default configuration files (schema.xml , solrconfig.xml). So, you need to replace this default configurations with yours by creating a symbolic link.
Check this post, it could give you an idea.
I need to move multiple symlinks within a VOB in a dynamic view.
As described in my previous question, this is not as trivial as it sounds (to me), as the target path is saved relative to the link itself and not to the VOB root or anything like that. This wouldn't be a big issue, if ClearCase would adjust the path information in those links, but appearantly, it does not.
Details: Let's assume following folder structure:
/myVOB
/Originals
/LinksA
/SubDir
/LinksB
Then moving a link to the file myVOB/Originals/readme.txt that is located in myVOB/LinksB to myVOB/LinksA/SubDir will prevent the link to find its target, as it is looking for myVOB/LinksA/SubDir/../Originals/readme.txt.
Does anyone know if it is possible to tell ClearCase to adjust the paths when moving symlinks? Usually I would think this should be done out of the box, but one never knows with ClearCase... Nevertheless, perhaps someone could try to reproduce this and tell me if it succeeded or not, perhaps it's just a bug on my system?
Edit: OK, so it looks like moving relative symlinks is not supported out-of-the-box. Would I need to move a great number of symlinks, I'd be writing a script right now that took a number of files/directories and moved them to a new location. If it encountered a symlink (whose target may be a file or directory) it would not just call cleartool mv or whatever, but follow the procedure as posted by VonC.
But I don't, so I'll probably do this by hand. Perhaps someone already wrote such a script, then this would be the right place to promote it ;)
If you consider this technote on "How to Manage symbolic links in ClearCase interop, it seems that:
(even if you aren't in an interop environment, ie even if your Windows views and Vob server are both on Windows)
symlinks are using primary relative path
you must recreate them if the target path change.
How to change a VOB symbolic link path
The only way to revise a VOB symbolic link to a relative path is to create a new symbolic link:
Note: You cannot edit (revise) a VOB symbolic link if it has been created using an absolute path to utilize a relative path.
-Check out the directory
- Remove the old VOB link using the cleartool rmelem command
- Create a new link with the same name
Example:
cleartool ln -slink -nc ../../same_file_name.txt
Check in the directory
Notes:
It is recommended that you use relative VOB symbolic links instead of absolute symbolic links.
The absolute VOB symbolic link requires you to use absolute path names from the view-tag level, for example, \view-tag\VOB-tag\filename.
Hence, they are valid only in the view in which they were created.