Simple question, but I can't seem to find the answer anywhere. Is there a way in Windows, or via a third-party utility, to enforce file naming conventions within a Windows network share?
I'm sure this is easy in Sharepoint, but I want to be able to limit users to the file name format they save into a folder. I could create a post-save program to go and look for exceptions after the fact, but I want to try and force the user to name the files according to our standards when they save.
If something is not available/configurable on the server-side, could this be accomplished via VBA in Excel or Word in the save-file dialogue?
Thanks for your help.
A
There is nothing, to my knowledge, that can restrict file names.
Nothing unless you write it yourself.
How about monitoring the folder for changes and as soon as a file with the "wrong" file name is created you alert the user in some way?
Idealy you'd want a "hook" of some sort on the file system level that will also let you fail the file operation if the filename is wrong; but I don't think there's anything at user (not kernel) level that does this.
You will have to write a program to act as a gateway to the share to enforce this. You'll also have to restrict access to the share so users cannot circumvent the program.
Related
I'm writing a tool with a GUI for OS X that is launched by the user only when needed, e.g. to delete locked files.
To enable the deletion of such files, root level access to the file system is sometimes required.
Currently, I solve this in a very simple way: The app relaunches itself using AuthorizationExecuteWithPrivileges. That leads to asking the user for an admin account and password. If he does that, the app runs as root and can perform its file access tasks as needed.
The problem with this solution is that it's fairly unsafe and bad style (the entire UI runs under the root user, for instance, which is clearly not desired). Furthermore, AuthorizationExecuteWithPrivileges is now deprecated.
How do I improve this? It's it clear to me that I need to write a helper tool for performing the file operations.
I do not want to use an installer, nor do I want to permanently give the helper tool root permissions in any other way. Instead, I want to require the admin to authenticate the operation every time, just like the Finder requires a user to re-login with an admin account whenever protected files are deleted or modified.
That means that the helper should get root permissions only temporarily. If AuthorizationExecuteWithPrivileges wasn't deprecated, I'd simply invoke the helper tool through that function, and I'd have my solution.
This means that SMJobBless is probably not the right way to go for me. Neither is launchd, it seems. What else is there?
Further question: What kind of inter-process communication should I use? Basically, I need to invoke the helper, passing some file refs (paths or URLs), and wait for it to return the results (including error msgs). I've found various ways for IPC, and I am more confused than ever now. Many reference launchd processes, which probably doesn't apply to me, so what should I look into?
I'm looking for a feature similar to CreateNamedPipe on Windows, which would allow programmatically generating file contents on demand. However, it would need to support seek operation as well, so plain named piped will not work, I think. Or does it?
Some details: The file will be read by other existing program, and changing that is not possible in this case. The two specific uses are: 1. the actual data is in a compressed binary blob. 2. the actual data is behind a network connection, accessed with a custom protocol. In both cases, the "virtual" file would give access to date as if it were a local regular file.
I'm sure this would be possible at least by creating a custom file system device driver, or using existing network file system and creating custom server program. But this sounds like very complex (is it?) and not worth the effort.
So, any practical efficient solution, other than just storing the data to regular temp file?
You need to write a kernel device driver, or take advantage of one of the existing user mode device driver frameworks, such as UMDF. You can start reading up on that on Wikipedia.
By using a FileSystemWatcher, in its events, I want to know the computer name or the IP or the user that triggered that event.
I know it's not possible directly with the FileSystemWatcher, but I was wondering if Windows stores that information for the File System.
So, could you at least point me where to start looking for it? If there's any Win Api to do such thing or something like that, even if in a very low-level?
EDIT:
Clarifying even more:
I wan't a low-level API or something of the sort that gives me the last user who modified the file in question.
My google search has led me to here: How to create a virtual file?
In that article, people suggested the author to extract the file to a temp directory and work with it from there.
Actually, what I would like to do, is something similar to what the author was originally asking - create a "virtual" file and assign a "path" to it, such that would be understandable by other applications calling standard windows filesystem API. The purpose of this is to prevent copying and unauthorized use.
A concept of what I would like to do:
In our company, we have developed a program - but it's not a standard EXE application, it has an internal format (let's assume the 'application' format's extension is .MDL) and is executed by runtime environment, so the runtime must be installed on the client machine. This concept is similar to Java (although this is not java; just comparing, so that you can better understand). What I want to do now, is to encrypt this .MDL file and include it as a resource in a regular .exe file. This .exe file would check if it's okey to run (check license conditions, keys, authorization etc...) and then, if authenticated, decrypt and extract the .MDL file, exec the runtime and pass the virtual path of the .MDL file as an argument to the runtime.
For obvious reasons, i don't want to write the decrypted .mdl file somewhere on the disk, because somebody could just start the application, wait for the decrypter to write .MDL to temp, copy it from the temp and distribute it.
So, any idea how to do this?
PS: I've got inspired from EA Games' games... when you run them and look into your process table, you see a regular game's exe, and, after certain time, it spawns a new process with name like ~A003.tmp
You should use boxedapp packer. It must help.
I am not aware of any method to have a virtual file associated with a path without using some kind of driver component; that is hard work.
Why don't you have the runtime do the decryption? Then you don't have to worry about decrypting the file on disk. Or you could create an unnamed inheritable section object to which to decrypt the item and pass the handle value to the runtime as a command line parameter.
Whatever you do, people will still be able to bypass it so it seems like a waste of time to me. Every EA game ever made has been cracked; people will either think your product is useful and worth the money or they won't. I don't think it is worth the time or effort to implement schemes more complicated than a very simple registration key check (just to make it look like you did something).
In what way is the Windows registry meant to be used? I know it's alright to store a small amount of user preferences, but is it considered bad practice to store all your users data there? I would think it would depend on the data set, so how about for small amounts of data, say, less than 2KB, in 100 or so different key/value pairs. Is this bad practice? Would a flat file or SQLite db be a better practice?
I'm going to take a contrarian view.
The registry is a fine place to put configuration data of all types. In general it is faster than most configuration files and more reliable (individual operations on the registry are transacted so if your app crashes during a write the registry isn't corrupted - in general that isn't the case with ini files).
Marcelo MD is totally right: Storing things like operation percentage complete in the registry (or any other non volitile storage) is a horrible idea. On the other hand storing data like the most recently used files is just fine - the registry was built for just that kind of problem.
A number of the other commenters on this post talking about the MRU list have discussed the problem of what happens when the MRU list gets out of sync due to application crashes. I'm wondering why storing the MRU list in a flat file in per-user storage is any better?
I'm also not sure what the "security implications" of storing your data in the registry are. The registry is just as secure as the filesystem - the registry and the filesystem use the same ACL mechanism to protect their data.
If you ARE going to store your user data in a file, you should absolutely put your data in %APPDATA%\CompanyName\ApplicationName at least - that way if two different developers create an application with the same name (how many "Media Manager" applications are there out there?) you won't have collisions.
For me, simple user configuration items and user data is better to be stored in either a simple XML configuration file, a SQLLite db, or a MS SQL Server Compact db. The exact storage medium depends on the specifics of the implementation.
I only use the registry for things that I need to set infrequently and that users don't need to be able to change/see. For example, I have stored encrypted license information in the registry before to avoid accidental user removal of the data.
Using the registry to store data has mainly one problem: It's not very user-friendly. Users have virtually no chance of backing up their settings, copying them to another computer, troubleshooting them (or resetting them) if they get corrupted, or generally just see what their software is doing.
My rule of thumb is to use the registry only to communicate with the OS. Filetype associations, uninstaller entries, processes to run at startup, those things obviously have to be in the registry.
But data that is for use in your application only belongs in a file in your App Data folder. (whiever one of the 3+ App Data folders Microsoft currently wants you to use, anyway)
As each user has directory space in Windows already dedicated to storing application user data, I use it to store the user-level data (preferences, for instance) there.
In C#, I would get it by doing something like this:
Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData);
Typically, I'll store SQLite files there or whatever is appropriate for the application.
If your app is going to be deployed "in the enterprise", keep in mind that administrators can tweak the registry using group policy tools. For example, if firefox used the registry for things like the proxy server, it would make deployment a snap because an admin can use the standard tools in active directory to set it up. If you use anything else, I dont think such things can be done very easily.
So don't dismiss the registry all together. If there is a chance an admin might want to standardize parts of your configuration across a network, put the setting in the registry.
I think Microsoft is encouraging use of isolated storage instead of the Windows registry.
Here's an article that explains how to use it in .Net.
You can find those files in Windows XP under Documents & Settings\\Local Settings\ App Data\Isolated Storage. The data is in .dat files
I would differentiate:
On the one hand there is application specific configuration data that is needed for the app to run, e.g. IP addresses to connect to, which folders to use for what sort of files etc, and non trivial per user settings.
Those I put in a config file, ini format for simple stuff, xml if it gets more complex.
On the other hand there is trivial per user settings (best example: window positions and layout). To avoid cluttering the config files (which some users will want to edit themselves, so few and clearly arranged entries are a must), I like to put those in the registry (with conservative defaults being set in the app if no settings in the registry can be found).
I mainly do it like istmatt sais: I store config files inside the %APPDATA% folder. Usually in %APPDATA%\ApplicationName, I don't like the .NET default of APPDATA%\CompanyName\ApplicationName\Version, that level of detail and complexity is counterproductive for most small to medium sized applications.
I disagree with the example of Marcelo MD of not storing recently used files in the registry. IMO this is exactly the volatile sort of user specific information that can be stored there.
(His example of what not to do is very good, though!)
To me it seems easier to think of what you should NOT put there.
e.g: dynamic data, such as an editor's "last file opened" and per project options. It is really annoying when your app loses sync with the registry (file deletion, system crash, etc) and retrieves information that is not valid anymore, possibly deadlocking the user.
At an earlier job I saw a guy that stored a data transfer completness percentage there, Writing the new values at every 10k or so and having the GUI retrieve this value every second so it could show on the titlebar.