Is it possible for someone with Administrator access to easily create arbitrary files (e.g. text documents) within the C:\Inetpub\wwwroot folder under Windows 8.1?
Normally right-click presents me with many file types I can create; here, I'm only given the option to create a new sub-folder, even though I can (i) edit existing files there or (ii) create files elsewhere and move them there. (Also, gvim running with administrator access can't create a (new) swap file there).
I created a subfolder ("test"), and took ownership of it, but it made no difference. One of my colleagues thought that this was a "special case" overridden by IIS and could be configured by the Group Policy Editor somehow?
I've heard that disabling UAC solves the problem, but I don't want to do that!
Any ways round this? (Reference to an existing discussion I missed would be fine if it covers the same problem). Thanks!
Smychi
Solved this; I added the specific administrative user account I was logged in under ("User") to the list of permissions and granted myself "Full Control".
Not sure why this didn't already work with the existing groups settings, though I'll admit my knowledge of Windows permissions isn't as good as it should be.
Feel free to say whether this is a good or bad way to do it, or add any comment to this anyway, for my benefit or for others who might stumble across this.
Smychi
Related
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
I want my installer to create a folder in C:\Users\Public\Documents that will be readable and writable to all local users. This includes the right to create files/dirs there, and to modify and delete all existing ones. The installer is being ran as Administrator.
I don't have to programatically set the permissions for my dir, right? Just by creating the dir, it will have the correct permissions I think.
I'm interested in the behavior under XP, Vista and 7.
Note: I'm not hardcoding the path C:\Users\Public\Documents, I'm querying CSIDL_COMMON_DOCUMENTS from the Win API, which can return different values depending on machine and OS. For example on XP it returns a different path.
Edit: here's a relevant discussion. It points to MS docs about the question, but it also looks like those docs may be wrong.
Yes, it inherits rights from the parent folder. Which has write permission for anybody in the INTERACTIVE group. Which includes any logged-in user account.
Use the Security tab in the shell's Properties dialog to review these settings.
If one chooses to "prevent other users from checking out and checking in" from Team Foundation Server:
Can anyone reach the code?
Is there any way to work from another user's computer?
How about shelving?
I would interpret that sort of lock as meaning that someone is going to do something so destructive that it is in your interests to not have an edited copy when that happens. If you think it is a mistake, talk to the person who locked the file.
An option, if you really want to do this, is to remove the readonly attribute on the file yourself (in Windows Explorer or through a shell) and edit the file. That is a good way to cause yourself trouble, though, if the file is going to be changed substantially by the person that locked it. Also, you will need to later mark it as checked out in TFS to actually check it in.
I do not think you will be able to shelve the file (unless you follow the option below) since you will not be able to check it out for edit.
One last option is that you could branch the file, work on the branch, and then merge it back in later. Once again, though, that may be difficult if the edits by the person locking the file are going to be extensive.
I'm not sure I understood all of your questions, but I'll give it a chance:
If by reach you mean, get latest version and read, yes they could. But they wouldn't be able to change the code while it's locked unless they circumvent Visual Studio and change the read-only attribute of the with the command-prompt, Windows Explorer etc.
Visual Studio and TFS 2010 introduces the concept of permissions on workspaces. A workspace now can be private (the old behavior), public limited or public. Using a public workspace, on could edit the files in the workspace of another person. See tf workspace /permission for more information.
You can shelve anything that is in your workspace regardless of locks on anybody's workspaces.
Here is a link to the permission values for TFS
http://msdn.microsoft.com/en-us/library/ms252587.aspx
This should answer your questions
I am working on a WinForm application, that allows working to work with "projects" (think about the application as Visual Studio, and projects as VS Solutions).
My question is - where should the application keep its logging files?
Some requirements include:
the application might not be running as an administrator (so saving in the %ProgramFiles% installation folder is not a good option)
The logs should be accessible to end-users (either for review, or for sending to the support team). (This means that hard to find folders, like %AppData%\Company\Application\Version\ProjectName... are not a good solution either)
The application might generate logs even when there are no open projects (so saving the logs in the project's folder is good only when there's a project, but not a final solution).
I was thinking of creating a "working folder" when the application is installed - something along the lines of C:\Application\, and then save the logs in a subfolder, like %WorkingFolder%\Logs\ProjectName
Thanks for the input.
Somewhere in the user's directory is actually the correct place to store them if they are specific to the current running user.
Some programs create folders at the top level of the User's directory, next to Documents and Desktop, others do it in Documents.
Creating it in C:\ might cause issues if the user doesn't have write access to the root directory. You can pretty much guarantee the user will have write access to the Home directory.
The other option is to look for an environment variable, and if its set use the value as the location, if not default to the User's home directory.
If the logs are user only you should store them at %AppData%\Company\Application Name.
If the logs are shared (any user can see any log) you should store them at:
%ProgramData%\Company\Application Name (for Vista+)
or
%AllUsersProfile%\Application Data\Company\Application Name (for XP-)
As for user access, you can add a shortcut to the start menu to the appropriate location or have a link within the program.
Another option in Vista+ is the Public folder (%Public%) which has links throughout Explorer for easy access to.
Where should I write program data instead of Program Files is a good blog entry by Chris Jackson from Microsoft. While it isn't an "official stance" it holds some excellent information.
You can always ask the user to configure this. Set a default path, maybe the application directory. During installation or while setting up the application you may prompt the user to input the path they want to use for logs. That's fair, right. If they're advanced enough to use logs they're good enough to configure a path too.
What do you plan to do with the logs. Are they technical, of for financial/security audits?
The EventLog is a nice place for technical logs, because you can access it remotely (within the Domain) and it is cleaned up automatically.
The %AppData% is also a good place for technical logs, specially if you are unable to connect to the eventlog. You can find the log files, and you can direct the end-user to them, but they are not "in the face" of the end-user. You can include a "send log to the maker" button to receive them.
For logs that needs be accessed by end-users, the My Documents (or a subfolder) looks good.
You can just to add button / menu item to easy open folder with logs.
Best place fo logs are %AppData%\AppName or %temp%\AppName.
Never use %MyDocs% or %Program Files%.
I'd suggest adding that question to the installer so that the user that installs the software can decide where best to put the logs. Though C:\[AppName\ sounds like a reasonable default for your requirements.
Edit: Just thought off, it would probably be worth warning the user if the select a bad location (in Program Files or in the root of the system drive etc) and if they choose to create a new directory, automatically give that directory correct permissions during the installation.
I think %APPDATA%\YourCompanyName\YourAppName is the preferred location. To overcome your stated objection of this location being hard to find, you could pretty easily and quickly implement a simple support screen in your app to allow the end user the ability to access and email these logs without too much trouble, so that the user will not have to remember or manually navigate to the long path name to get to the logs.
I don't really like the idea of the user being able to set this location via the installer because of possible naming and permission issues.
If the app needs to maintain the log only for the users current logged in timespan, then you could keep it in c:/temp.
Most of my winapps, i leave it there, so automatically it gets deleted once the user logs off..
Ofcourse, this primarily depends on your requirement.
Over the years I have vacillated between having my project/source folders in a directory one level removed from the root (e.g. D:\Projects) and keeping them in the default location for Visual Studio.
In the past, I resisted storing anything in the various "My Documents" folders established by Win 95, Win 98, and XP. I finally switched to storing them in the Documents folder since Vista shortened the path and I got tired of changing default directories for my dev tools. However, now I find myself leaning toward creating a folder off root again since I am setting up a new machine.
I get tired of the long paths you have to navigate to when stuff is stored in the documents folders. Also, I don't backup source code and database files like I do with my other documents since I use a VCS for source code. However, it seems you are always fighting to maintain a "non-standard" source location since every dev tool generally wants to store stuff in a subfolder of documents.
I would like to hear other's opinions on this subject.
I think it depends on your use... I prefer to have my development projects on a separate drive/partition, so will usually use the following convention D:\projects\{company-name}\({client-name}|internal)\{project-name} Where the client-name comes into play is when the work is by a given company, but for another. I keep my projects under D:\projects\personal\... This allows for a better structure.
As to backup strategies, imho this is what source control is for. I prefer subversion, and have a backup strategy for the svn server. Although I didn't much care for ankh 1.x, the 2.x version, along with TortoiseSVN have worked pretty well for me. As a matter of practice, I tend to checkin often, and try to only checkin code in a runnable state (though new features/code may not work).
In clear violation of my Unix past I use c:\dev (for development) or whatever other drive I use for development. Note: It is advisable NOT to use the system partition for development as software development really fragments the disk.
I never had any reason to use another directory - except for some projects where "company standards" forced everybody to have the development directory on the root of the C: drive. (really! They had hardcoded paths to c:\whatever)
During development I sometimes check out multiple versions of the source to different directoies - if only to find out that the version committed into the version control system of the day really has every file checked in. (Sometimes I add a file to the development directory but forget to check it in.)
So I think it is rather irrelevant where your development directory is, as long as the path is typable for you (I prefer short paths) and does not contain white space for the usual reasons on windows (if you want to do some scripting).
I preferred location at another partition. Because projects have many and many small files and if you use SVN or other revision control system this files have very high fragmentation and slowing system if are storing at OS partition.
I haven’t tried it myself, but I guess you can put your projects in My Documents and use a symbolic link to the directory in your root folder. By doing that you can access your files both ways and solve problems like changing directory for tools. Info about symbolic links in Vista
If you’re the only one using your computer I don’t really see why you should put your code in the profile directory, backup should be done using a version control system anyway.
I store "active" projects on a secondary drive, one level from the root. It's much more easy to get quickly to that folder (even if VS2008 has this nice "Open Folder in windows explorer" now). It's also convenient for backups, format/reinstall, etc. The "less active" projects are stored on a NAS for quick reference. All are also stored on a remote SVN server that is backuped. (I'd also recommend not using # in folder for web application as it (sometimes) create strange errors from the development web server)
I use SUBST (run on startup) to map some random folder to a high-lettered drive. Then I can put my stuff anywhere, and move it around, and yet I always get to refer to it by Y: or Q: or whatever.
This is one of those extra layers of indirection that are said to solve every problem.
For personal projects I just put them on the desktop (although I do move the desktop to D:\Desktop). They are archived off to my documents when they become inactive.
For work I have all the projects in a C:\Sourcecode folder inside a dedicated development virtual machine.
Just one question, do your primarily develop desktop apps or web apps?
If you are constantly writing web apps, here's what works for me:
Create a folder: c:\dev or c:\sites (keep it simple)
Register the folder as a virtual directory in IIS
Create a different folder for each of your projects and create a web application in IIS for each of them
One advantage this setup might have is that, its easier for you to navigate your site in the browser, i.e less typing, easier to remember, standardization for all your other apps.
my 2cents.
it is better to keep your project in the other partition else than window and i think as i do
d:\projects\"some grouping of project own your own choice"\projectname
e.g.
d:\projects\UNIversty\admission
d:\projects\universry\examination
d:\projects\planners\ipp