I want to open a file, while ensuring that no component of the path goes outside a certain directory.
On Linux, I can accomplish this using openat2 and RESOLVE_BENEATH, and on FreeBSD there is the O_RESOLVE_BENEATH flag with openat.
Is there any way to achieve the same effect on Windows? Note that this needs to be on a per-call basis — globally restricting my process to a given directory is not useful.
In a 32bit application, I have to copy a file to the 64bit system folder
(C:\Windows\System32\ instead of C:\Windows\SysWOW64\)
For this, I tried to get the folder using the WinAPI function SHGetKnownFolderPath with parameter FOLDERID_ProgramFilesX64 (GUID: 6D809377-6AF0-444b-8957-A3773F02200E).
But unfortunately, this is not allowed (as mentioned in the remarks section) and the function result correctly is 'file not found'.
Is there a way to accomplish this?
You are requesting the PROGRAM FILES folder, not the SYSTEM folder. Look at FOLDERID_System and FOLDERID_SystemX86 instead.
Alternatively, use FOLDERID_Windows to get the Windows installation folder, and then append the special SysNative alias to the end of it, let the File System Redirector locate the actual folder for you, per the documentation:
32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.
I'm confused why you would try FOLDERID_ProgramFilesX64 when you say you want the System32 folder, since the former would (if it worked) give you the Program Files folder. For the System32 folder, you want the GetSystemDirectory function.
You can use the catchily-named Wow64DisableWow64FsRedirection function to disable WOW64 redirection, which allow your 32-bit app to actually access the 64 bit system folder. Then use Wow64RevertWow64FsRedirection to restore the redirection once you're done.
Also note that it's not actually recommended to store your own files in the System folder any more (and hasn't been for quite some time), as this note in the docs for GetSystemDirectory says:
Applications should not create files in the system directory. If the
user is running a shared version of the operating system, the
application does not have write access to the system directory.
Windows has several "virtual folders" and "special folders" (Wikipedia's names for them) that change the way the file system works. For example, the Desktop folder acts like the root of the file system hierarchy in some circumstances, even though C:/ is the drive, also called the partition, that the entire file system is on, and therefore logically Desktop should be under C:/. Screenshots: There are also the Library folders. Also, with msysGit and Cygwin on your computer, the program's folder then magically becomes the root of the file system.
I'm sure there are instances on other OS's, but I only really work with Windows, although it seems Linux is much less abstracted.
How do applications do this? Is it just a really complicated shell script, or something that only affects certain programs (Wikipedia says Desktop is only the root folder in Windows Explorer, for example)? Is it similar to how on Linux all folders are "mounted", even the root folder? Even if the OS developers don't usually give away their secrets, I would still like to know the basic method, if possible.
So, wikipedia's entry for special folder says that:
The Desktop virtual folder is the root of the Windows Shell namespace,
which contains other virtual folders.
This is not the same as saying it's "the root of the file system hierarchy". Windows has a set of set of virtual folders. All of these are nested under Desktop.
For Win7 and up, the default filesystem layout is actually:
Desktop -> C:\Users\(username)\Desktop
My Documents -> C:\Users\(username)\Documents
Downloads -> C:\Users\(username)\Downloads
These aliases mean something to the explorer shell, but not at the filesystem level (open cmd.exe and see what I mean).
At the filesystem level, and to an application, the filesystem path is what is going to matter. It takes extra API calls (the use of SHGetSpecialFolderPath()) to figure out where on the filesystem that special folder lives; the app only cares about where in the filesystem it needs to target.
As for Cygwin, I strongly suspect that it's doing something totally different. Unix has a special call, chroot(), that really does modify the root for the currently running shell. This means that applications running under that shell have absolutely no knowledge of the directory structure below the chroot()'d path, and this is generally done for security reasons. In fact, this is usually referred to as a chroot jail, because it isn't an alias or a virtual directory, and can't be escaped from (unless there's a bug in the kernel).
Linux has a feature called namespaces, which let you give a different "view" of the filesystem to different processes. In Windows terms, this would be useful for example if you had a legacy program "floyd" that always loaded its configuration from C:\floyd\floyd.ini. If Windows had namespaces, you could write a wrapper script which would create a namespace in which to run floyd, making it so when Alice ran the script, floyd would start up in an environment where C:\floyd existed but actually pointed to C:\Users\Alice\Floyd.
Now you may be thinking, "OK, just use soft or hard links and make C:\floyd an alias for C:\Users\Alice." But with namespaces, Bob can also run the startup script, but his instance of floyd (on the same computer, running at the same time) will see C:\floyd with the contents of, say, C:\Users\Bob\Program Settings\Floyd Config (or any other path we like).
You can do this on Linux with namespaces. Is there something similar or analogous on Windows? It's fine if it requires writing a C program, and it's OK if it only works on recent versions of Windows.
NTFS hard links are really a simple case of reparse points. Reparse points are typed, and can include more advanced behavior. For instance, they're also used for "offline storage" (transparent migration of files to and from secondary storage). You can therefore also use reparse points to implement per-user symbolic links, by creating a new reparse type.
The reparse point type even has an explicit "Name surrogate" bit, which (if set) indicates that reparse points of those types are some kind of symbolic link.
You can even have multiple reparse points in a path. Therefore files inside your symbolic namepace can still be migrated to secondary storage - you'd just have two reparse points in the path.
I think Virtual Store does this automatically for legacy programs that try to write to nonstandard directories. So the legacy program writes to a user- and program-specific directory instead to C:\floyd.
This sounds like Windows Vista's file system virtualization. For example, it can silently redirect c:\Program Files\Floyd to c:\Users\<username>\AppData\Local\VirtualStore\Program Files\Floyd. However, file system virtualization isn't nearly as configurable as Linux namespaces. From what I can tell from reading, file system virtualization should apply any time a 32-bit interactive process opens for writing a file, folder, or registry key that's only writable by administrators. (So you typically end up with some read-only files under c:\Program Files and some per-user writable files under c:\Users\<username>\AppData\Local\VirtalStore.)
An application virtualization product can probably also do this, although those are often more complicated and more expensive.
You can use hardlinks for that, but only with NTFS. http://en.wikipedia.org/wiki/Hard_link
I think windows doesn't have virtual FS view per process.
The most relevant thing is probably special environment folders, such as %temp%, %appdata%, %localappdata%. Not that they're equivalent, but they fulfil the same purpose.
You can define your own environment variables then use '%myspecialplace%\myfile.txt' to access them.
As a horrid kludge (and here I book my passage to programming hell) could you use a NamedPipe for C:\Floyd that mapped the IO operations onto a file specific to the current process user?
I know it's not pretty and I don't know enough about NamedPipes (FIFOs in other dialects) on Windows to know how feasible this is.
Dan
There are several things that come to my mind.
First of all you can create a file system filter driver (or use a ready driver, such as our CallbackFilter product) that would redirect all file system calls, coming from the application, to other location. This is close to virtualization that you mentioned but this won't change the list of drive letters though. Such approach is both powerful and non-trivial, so see the other option first of all.
And the other option is:
there exist several products (Thinstall, Molebox if memory serves) that "wrap" the application redirecting it's file I/O to some other location. There was also some SDK to do the same, but I don't remember it's name at all.
e.g. http://www.msigeek.com/4819/file-re-direction-using-correctfilepaths-shim-to-fix-broken-applications
But I think it's not configurable per user, although the target can vary per-user based on environment variable substitution.
Most programs, though, store configuration in the registry, in which case RegOverridePredefKey would do the trick.
There's a shortage of good solutions for this. For simplicity, I can't improve on using NTFS soft links (junctions) for this - as you correctly point out, this creates issues if you want per-user configuration. As MSalters correctly says, all NTFS soft and hard links are just special cases of reparse points, so you could do something more general by impplementing a new reparse type, if you don't mind some work digging into NTFS..
(Junction is a pretty useful tool when experimenting with NTFS soft links: http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx )
You could just take a direct approach - give each user (or your program initialization if you only care about one piece of software) a logon script that sets up the appropriate junction into their user directory (and make sure you clean it up afterwards). But it's clumsy.
In general the right Windows approach is to put things into the folders pointed at by the %localappdata% (from Vista on) and, more generally, %userprofile% system variables.
Win file system virtualization is intended to ensure this in the cases where it applies.
I am looking for an acceptable starting point for placing applications settings in a Windows machine. I have more than one application. for personal reasons, I wouldn't like to use the registry: I prefer plain text initialization files (.ini). I also don't feel like holding the files in the same directory as the executables, the ideal situation allows me to keep them somewhere generic where users or system administrators are allowed to write.
right, I'm not a windows user, my first guess would be $HOME/.my_company_name and /etc/my_company_name, but is there something conceptually equivalent to these places in Windows?
just looking into the SET output and guessing:
%APPDATA%
%HOMEDRIVE%%HOMEPATH%\Local Settings
%SYSTEMROOT%
by the way: I still must check whether these variables still exist from within a windows service...
I think AppData is what you want.
You can use SHGetFolderPath (from SHFOLDER.DLL) to get this programmatically.
From MSDN 'Data and Settings Management' (see section 4.2 'Classify and store application data correctly'):
TCHAR szAppData[MAX_PATH];
…
hr = SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, szAppData);
Append [company name]\[product name]\[version] to szAppData using PathAppend:
PathAppend(szAppData, "Company\Product\1.0\File.ini")
There is also CSIDL_COMMON_APPDATA for non-user specific data and CSIDL_LOCAL_APPDATA for non roaming data (data that shouldn't be copied across the network when user logs on to a different machine).