I have created a Google drive folder which is shared with others. I am trying to take regular backups of whatever docs are created in that folder using xcopy. While uploaded files are getting backed up, created files such as docs etc., are not. Command line throws the error "target folder does not support symbolic links".
I tried changing privileges in windows administrative tools to include other users to be able to create symbolic links but still it didn't work. Help please!!
The structure of the family directories, as outlined in the docs requires every image to be placed inside the images directory. However, the OptaPlanner documentation contains both images and asciidoc files in the same directory per chapter. Please see the directory structure below:
https://github.com/kiegroup/optaplanner/tree/main/optaplanner-docs/src/main/asciidoc
Changing the current structure is undesired due to existing references from external repositories (breaking backward compatibility).
Is there a way of configuring Antora to pick up images from the pages directory and its subdirectories?
No.
The best-practices answer: Antora requires a specific directory structure and you have to adopt it.
You can adjust the Asciidoc markup to achieve this goal:
image::./relative/path/to/image.jpg[]
However, doing so could break your compatibility.
Antora 3 (currently in alpha) will provide symlink support, so you could create symlinks in the images folder that point to the images within the pages folder. Once that is in place, you can refer to those images like any other image in the images folder.
With Antora 3, you also could write an extension that locates images within the pages folder and add them to the contentCatalog as if they had been in the images folder. That would be notably more effort.
For the purposes of a security test involving Windows servers, I would like to attempt uploading a Symbolic link to a Windows web application. However, based on the information officially available, it is unclear whether Windows hard links (Which I suppose are the same as NTFS junctions) exist as a file that can be copied from the hard disk the same way it does on Linux. It's vague, but I get the sense that NTFS junctions are some other kind of file system artifacts which is different than "regular" files - I can't find the documentation to confirm or deny this. I.E NTFS I want to know if NTFS supports the direct manipulation of the symlink record such that I could move the symlink to a different computer.
I am aware that Windows softlink files (.lnk) are not limited in this way, but they do not suit the purposes of the test.
My Aim is to copy a symlink off of a virtual machine, and then upload it to the server which I am testing.
Is this possible? (I am under the impression it is not.) From what I have seen absolutely every program on Windows would regard the hardlink as the destination file. Is there a way around this, perhaps by using a special editor to temporarily corrupt the file? If the symlink exists as a normal file on the file system can the symlink be altered so it can moved to a non-Windows OS for further use?
Let me know if this would be a better question for server fault. Since this is not directly about security, and is more of mundane technical problem in the service of a security exercise, I don't think it would fit on Stack Exchange security.
It's hard to provide a very direct answer. I work on a backup/repair/imaging project, and I copy whole disk images to a server via a web service - so, it's possible to do what you want, but there's a lot to consider.
Hardlinks
It is generally assumed that hardlinks cannot be distinguished from each other, however, there is a subtle difference between linked files and their "original" file. That difference is that queries to the $MFT (using USN-related arguments on the winapi function DeviceIOControl) will only return one of the files. This may be considered the original file. You can then call the winapi function NtQueryInformationFile to enumerate the hard links.
Symlinks and junctions are different animals...
You can know that a folder is a junction or a symlink, by getting the attributes from it. There's a ReparsePoint flag in the attributes if it's a junction or a symlink. BTW - the difference between junctions and symlinks is that the junction is a redirect to another location on the same volume, while a symlink is a redirect to an off-volume location. The redirect target is always another folder either way.
What's interesting is that both symlinks and junctions look and act like folders, while they are really files containing redirect information. When you open 'em, NTFS will normally look at the redirect, and open the redirect target. NTFS checks the permissions at the redirect target, so as an attack, this might not be a robust strategy.
When opening a junction/symlink, you can add a flag FILE_FLAG_OPEN_REPARSE_POINT. When you do this, NTFS does not perform the redirect, but opens the content, which is actually redirect information, and assuming you know the format of that information, it is possible to reconstruct the junction/symlink at the server. Note that the redirect may point to a location that may not exist, or may exist only temporarily. This is expected as some network resources may not always be available.
So, in short, it's possible to copy a junction or a symlink...while copying a hard link nominally means copying the file...with the foregoing subtleties in mind. You can create a hard link manually, too, as long as the target file exists.
With hardlinks, there's one interesting kink in the NTFS security picture. If a user has access to a file, and you create a hardlink to that file in a folder the user doesn't have access to, the user can still open that file using the path to the hard link. This is because the link and the original file are both pointing to the same file (and security info) on disk. Permissions changed on any of the links affect all the links. Without knowing this, you can inadvertently wreak havoc on a file system :-)
I know this is a bit helter-skelter, so let me summarize this way:
NTFS directory entries can be folders or files. Hardlinks are directory entries that all point to one file. Symlinks and junctions are really files that act like folders for most practical purposes (until you know how to get at the redirect info as described above).
AFAIR, NTFS (directory) junctions are actually symbolic links. The juctnion is implemented as a special file attribute called repars point that contains the link target.
Hardlinks, on the other hand, are implemented as direct references to the base MFT record of the target file and are stored as regular entries inside directory tree. You actually cannot distinguish a hardlink from the "original" file (every file and directory actually has at least one hardlink since it is contained somewhere within the directory tree).
If you wish to copy a symbolic link itself, you need to know that it is a symbolic link and extract the information about its target. File operations (except deletion and, probably, renamng) are redirected to the link target. So, you can, in general, copy a symbolic link by creating its exact copy in the destination area.
The actual question is, whether the interface you are using to perform the copy operation allows you to create symbolic links on the target.
How do I decide which of my application's files go in Program Files (FOLDERID_ProgramFilesX64) and which go in ProgramData? (FOLDERID_ProgramData)? I don't understand what the reason is for splitting up my application's fixed files into these two categories or how I should decide which file goes in what.
For example - image files which my application displays, are they "program" or "data"?
Is there any problem with just putting everything under one or the other?
The application is installed for All Users and has no user-specific configuration files or data.
Program Files is for executables and other static files that came as part of the installation. ProgramData is for user-agnostic data generated during execution such as shared cache, shared databases, shared settings, shared preferences, etc. User-specific data goes in the AppData folder. Note that these are for non-user-visible data. User-visible data belongs in the documents folder (or music, video, custom sibling folder, etc.).
Please see Special Folders and Custom Folders for a detailed explanation. Note that the terminology used varies slightly between the name used in the documentation here, the name of the folder, and the name used by various enumerations used to get these paths from the system.
I have added support for Windows symbolic links in our application using the CreateSymbolicLink function. Our application stores data across a set of actual folders. Our users needed to store some folders outside of one main root folder. The solution we chose was symbolic links. This lets them do things like keep a subset of data in DropBox or stored out on a network drive. So far everything has been working great.
When using Windows Explorer, Windows will show the following message if the link target is not present. This could be caused by a target being renamed or a remote network drive not being available.
Location is not available
C:...\MyLink refers to a location that is
unavailable. It could be on a hard drive on this computer, or on a
network. Check to make sure that the disk is properly inserted, or
that you are connected to the Internet or your network, and then try
again. If it still cannot be located, the information might have been
moved to a different location.
I am trying to duplicate this check and add the target location so users can tell why no data is present.
A normal directory exists check is not sufficient because the symbolic link is present on the system. I have worked around this by calling CreateFile to open the folder. This causes the target location to be opened instead of the symbolic link. This does fail as needed for my check. Now I am stuck trying to get the target path that the link points to.
I have found this answered Stack Overflow question for reading the Target Location from a symbolic link.
- How do I programmatically access the target path of a windows symbolic link?
However that answer requires a valid handle from opening the directory. In my case I want to find the name for a broken link to help with trouble shooting and fixing the link.
How can I get the target location of a symbolic link without a valid handle?