What is $Secure:$SDS:$DATA on Windows? - windows

One of my customers has seen $Secure:$SDS:$DATA show up on their drive and it keeps growing while my app is running. I don't (knowingly) write to this file, and don't use any type of Windows secure storage (which might be related). Kind of stumped...
Any thoughts on what this might be?

From what I gather it's a metafile for NTFS. Does your app handle anything related to user access or NTFS permissions on files?

Related

The intended usage of /Library/Application Support/ on OS X

My understanding is that the system-wide application support folder (i.e. /Library/Application Support/ as opposed to ~/Library/Application Support/ ) should be used by applications for storing files that are shared by all users on the machine.
What confuses me, however, is that the regular user does not have writing permission into it. Assuming that messing around with file permissions is not the correct way to go, what is then the usage of such a folder?
I have checked out an application that uses this folder (VirtualBox) and it seems that it creates its own subfolder and writes onto it during installation only (when admin credentials are active).
Initially I thought /Library/Application Support/ was used very dynamically by applications during normal usage, but I am starting to suspect I was wrong. This folder is very rarely written into (possibly just once) and is mostly used to read from.
Am I correct? If so, where is the recommended place to write user-shared application data that is frequently read and written?
'All Users' also imply superuser permission.
I think, [/Library/Application Support/] best suit for the Privileged Helper Tools.
Am I correct? If so, where is the recommended place to write user-shared application data that is frequently read and written?
For this purpose, there is [/Users/Shared/Library/Application Support].

Silverlight 5 Trusted Mode. Accessing FileSystem and Local drives

Is there any way, any chance at all to access entire filesystem in SL app with elevated trust?
That will work both in Windows and Mac?
Through AutomationFactory,PInvoke or unmanaged code?
I need an app that could read local drives, folders and files.
UDP: Ok, seems it's possible to read folders and files using classes of System.IO from mscorlib. Although you still can't get information about local mounted drives. There is no DriveInfo in Silverlight's mscorlib :(
Ok I have an idea about this.
It is straightforward enough with Windows, to get the list of the local drives you can use AutomationFactory. There is plenty amount of examples if you google it. Search for something called SilverlightFileExplorer.
Now on a Mac you can use Directory.EnumerateDirectories("/") and then it gets all the folders in the root. Including Volumes folder which contains shortcuts to the local drives. I'm not an expert of Berkeley System Distribution (BSD) Unix filesystems, so I can't really promise that it would work on any Mac, but this approach works on mine.
I'm still playing around with that. When I get working prototype I'll probably share it through github or something.

Does Windows 7 restrict folder access as Vista does?

I noticed that in my application, most compatibility problems were caused by 'access denied' for some folders, such as:
Application Data [C:\ProgramData]
Desktop [C:\Users\Public\Desktop]
Documents [C:\Users\Public\Documents]
Favorites [C:\Users\Public\Favorites]
Start Menu [C:\ProgramData\Microsoft\Windows\Start Menu]
Templates [C:\ProgramData\Microsoft\Windows\Templates]
Does Windows 7 have the same problem as Vista?
With help from the members of Stack Overflow, I know that on Vista I can use CSIDL_APPDATA to enable the file access without UAC problems or 'access denied' errors.
Is this also valid for Windows 7?
It's not a "problem", it's a feature. It's called User Account Control (UAC), and it's one of the ways that system security was tightened under Windows Vista. Windows 7 indeed retains a similar security model.
There's absolutely no reason that your application should need to mess with system folders in the first place. As you've already learned, Windows provides a number of locations for applications to store data, both temporarily and permanently. Microsoft has been recommending for a long time that you take advantage of these folders: they were the preferred location for storing data even under previous versions of Windows. The fact that you ignored this advice, yet your application continued to work, was actually the bug. The fact that later versions of Windows finally closed that security vulnerability, thus breaking your application, should be neither unexpected nor unappreciated.
You can find more information about where to store your data on this page. Also see this blog article, which attempts to summarize the array of technical documentation into a handy table. And as always, Raymond Chen provides a simple, yet instructive, overview of the differences between the locations:
The most important difference between My Documents and Application Data is that My Documents is where users store their files, whereas Application Data is where programs store their files.
In other words, if you put something in CSIDL_MYDOCUMENTS (My Documents), you should expect the user to be renaming it, moving it, deleting it, emailing it to their friends, all the sorts of things users do with their files. Therefore, files that go there should be things that users will recognize as "their stuff". Documents they've created, music they've downloaded, that sort of thing.
On the other hand, if you put something in CSIDL_APPDATA (Application Data), the user is less likely to be messing with it. This is where you put your program's supporting data that isn't really something you want the user messing with, but which should still be associated with the user. High score tables, program settings, customizations, spell check exceptions...
There is another directory called CSIDL_LOCAL_APPDATA (Local Settings\Application Data) which acts like CSIDL_APPDATA, except that it does not get copied if the user profile roams. (The "Local Settings" branch is not copied as part of the roaming user profile.) Think of it as a per-user-per-machine storage location. Caches and similar non-essential data should be kept here, especially if they are large. Other examples of non-roaming per-user data are your %TEMP% and Temporary Internet Files directories.

Mounting archives such as *.zips (work in kernel mode without drivers)

I was wondering if there was a way to make a *.dll that mounts archives in Windows without the need for installing drivers. I've tried mounting *.isos (and was successful), but I needed to install drivers, which was not something my intended audience wants to do (or can do). The other relevant alternatives were for Linux (fuse-zip) or dead projects (zipios++).
Something along the lines of this...http://mountziplibrary.codeplex.com/
Oh, and it'd be great if the solution was GPL v3'd or at least open source.
Thanks.
Have you looked at Dokan? It looks like a Windows equivalent to Fuse.
What you're describing is called an Installable File System (IFS). It theory you don't need a driver: implement a SMB server in application space, and let the existing kernel network client talk to that. It's just TCP/IP at that level.
The proper solution is indeed an IFS driver. Fundamentally, drives are objects in the kernel namespace. As such, the code for them should be part of the kernel, and an application never is.
There was a hobbyist project called WinFUSE once, which worked as an SMB server and redirected FS requests to your .NET code. But it's gone, as far as I know. Proper way is to use a driver-based approach. The driver can be installed and removed on-the-fly if the user has admin rights, and if he doesn't, installation of the application requires admin rights anyway. In Unix/Linux it's the same - you can't mount a disk (not saying about the driver now) if you are not an admin. Could I not mention that Callback File System is the only professional supported solution that lets you accomplish the task?
I've decided to Google around for some answers.
One of particular interest was zziplib. It's for C and transparently accesses archives, just like Windows does, treating it as an actual folder.
Of course, the other implementations given by users work too. This one just fit the bill for me.
Maybe this one helps you: ZLib

How do I update a VB6 app from XP to Vista?

I work on a vb6 application which is having problems with Vista, for the obvious reasons (writing to program files, and other things that are no longer allowed by default).
Where should I store application data or user's saved files?
Do I need priviledges to create folders and files, there, too?
What other common actions will cause problems?
The program has an updater which must download and register files, how do I elevate priviledges when this occurs?
Some of these questions have obvious answers, but I want to get the obvious stuff right.
Depending upon what you are doing, you might be in for a world of pain. There are no hard and fast answers to any of those questions, but from someone who is going through the same issues right now, here's what I know.
1) Where should I store application data or user's saved files?
This depends on what you are wanting to do. If you want them per user, store them in Users/AppData, if you want them for all users, store them in Common/AppData
If SHGetFolderPath(0, CSIDL_COMMON_APPDATA, -1, SHGFP_TYPE_CURRENT, sTempPath) = 0 Then
sCommonAppdata = Left$(sTempPath, InStr(1, sTempPath, Chr(0)) - 1) & "CompanyName\AppName"
End If
Change that to CSIDL_APPDATA for the Users AppData directory. Note: These map to totally different places on the filesystem for XP and Vista so when you are debugging prepare to look in different places.
2) Do I need priviledges to create folders and files, there, too?
You need Adminsitrator access to write anything in Program Files, if at all possible don't do it! We are currently running into issues that the API's for VB and the standard API's behave differently on files in Program Files.
3) What other common actions will cause problems?
There are lots of hidden gotchas. Just to name a few, you cannot communicate through IPC or Named Pipes to other applications (we have a Service that we were talking to through a Tray Notification Icon and that had to be completely re-written). Anything were you see a UAC notification is very difficult. Also you cannot write to anything in the Registry in LOCAL_MACHINE without Administrator, so you either have to stick to LOCAL_USER or raise credentials (see below).
4) The program has an updater which must download and register files, how do I elevate priviledges (sic) when this occurs?
Good luck with this, I highly recommend that you don't write it in VB6, like I said, the VB6 file api's appear to access files differently from the standard API's. If you need to elevate privileges see this post that someone kindly helped me with.
In the sort term turning off UAC and installing the ActiveX installer server will help. Long term you need to put data and configuration information in the users directory under \users or in \programdata.
In the short run it might not be necessary at all to modify your application, because
Vista comes with a set of compatibility options to allow legacy applications to run. This includes file and registry virtualization, a feature which basically redirects write operations to protected folders such as C:\Program Files to a virtual location only visible for the specific application running in a compatibility mode.
Some more details are mentioned in this article: How To Manage Windows Vista Application Compatibility in Dr. Dobb's.
Karl Peterson wrote a nice article on where to store user data & app data, with a VB6 class that retrieves the location of the special paths for you.

Resources