I have a question for my readers, consider this an informal architectural review.
Consider the following conversation, what would your next reply be?
Application Development:
"We need the install to modify the ACL permissions under [ProgramFilesFolder]CompanyName\Logs and set it for all users to have modify."
Installer Development:
"It's not a best practice to store user data /logs in Program Files. You should consider writing your file to another location."
Application Development:
"But I see plenty of companies that write log files under ProgramFiles. I disagree and I think that the install should go ahead and change the permissions."
What would you say next?
What would your response be?
15 comments:
I would suggest the location to be under user application data folder or %temp% directory.
If I were in your shoes, I'd demonstrate this not-so-implausible scenario.
On an NT6 machine, install the application and make their requested ACL changes under 'Program Files\'. Then, come along with another account in the Administrators group and "fix" the permissions on the folder under 'Program Files\'. Go ahead and run the app and see how it responds to having log files virtualized. Then show how the log files aren't there when navigating to the folder under a different user account, or some other such NT6 awkwardness.
I'm sure you could also dream up some sort of network exploit.
Tell them to read Microsoft's Windows programming guidelines. It's quite an interesting read. Had every developer followed it (and I also mean the guidelines since Win2k) there would be much less UAC complaints and problems(although even then there would still be too many UAC popups IMO).
Besides in future Windows versions writing to ProgramFiles might prove more and more difficult ((un)installation excluded, of course) even for the application itself during runtime.
Writing to AppDataFolder is the way meant by Microsoft how to store application data, either common data or user specific data. And with Vista they began to enforce this.
Counter question: What's the advantage of storing those files in ProgramFiles?
First, we are not like "plenty of companies". To be a good professional software engineer, we have to strive follow the guidelines set out by the OS provider (MS, in this case) in order to correctly integrate into the OS for full and proper support. "Plenty of companies" do software, but that doesn't mean that they didn't cut a corner somewhere.
Second, log files (as with most application generated files) should be in the user application folder or the specified temp directory (as mentioned by nikhil).
Third, the install should not be treated as a workaround for application development laziness or incompetence. Application development should have the responsibility to write solid code. (Try to massage that into a little less offensive language, but the point still stands.)
Marcus nailed it: point them to the MS application development guidelines and point out the reason so many applications are having problems on Vista is because 'plenty of companies' didn't follow the guidelines.
Tell them to RTFM!
If it is application logs, potentially they should consider writing it to the System Event Logs. This makes application administration easier, because if something goes wrong, sys admins should be going to the event viewer to see what is happening rather than crawling round to find where a text file log has been written.
Definately resist, I use %temp% or on our client/server app the server folder that contains the database files. I have a client who has some very strict policies and would probably change back your ACL change via a group policy.
not really too fussed either, being a repackager as opposed a packager (more often than not). I found they both seem to work although in preference I like to see the data / logs elsewhere.
in saying that however I wouldn't be using [ProgramFiles]Appname\logs I would be using [Appname]logs the former is bad practice.
As the other psoters already pointed out, it's not good practice to have to application store log files in the program files folder. And it's potentially dangerous to open up permissions there.
Ask the developer whether there's an important technical reason/need for ignoring the documented best practices and storing the log files under program files. "Others do it also" is not a reason.
Modifying ACLs requires administrative work and application level modifications to ensure that the ACLs haven't changed. This incurs a maintenance and support cost to oversee. If they have then a message has to be displayed to the user so that they can resolve the issue, which means we have to translate another string and add an acceptance test for this case. Additionally, we may have issues with companies and governmental agencies that require security standards follow specific policies laid down by the company.
Or we can store it to AppDataFolder, which is where the user will expect it to be and a location we get for Free. It will require minimal testing and offer the company support and maintenance savings as well as "future proofing" the application.
(late to the party, but...)
My fellows have all responded by saying why logging to [ProgramFilesFolder]... is a bad idea -- and I agree -- but I wonder if we're solving the right problem.
If "Application Development" is a non-technical manager, or a relatively inexperienced programmer, whose argument is essentially "I think I saw it done this way once on Windows 98, so therefore it's unarguably Best Practice", then it's a question of education. And the first step in educating is, not to explain, but to persuade the student to accept that he has something to learn. Not always easy to do.
A related question that someone -- perhaps not you -- might need to ask him is, "what qualifies you to make decisions about the customer experience?"
By way of illustration, let us translate this into Unix: your customer explains to his sysadmin that "we've just bought this product and it writes its logs in a subfolder of /usr/bin. Oh, yeah, and it makes it world-writable, thought I should mention that..."
Pop quiz: the sysadmin will
a) have the customer committed to an asylum
b) eviscerate you, the developer, out of your uvula
c) have your company arrested and hanged for crimes unbecoming a software vendor
...the question being, of course, which will he do first?
First and foremost, it seems, install engineers must be teachers.
p.s. the app-dev's comment that "the users expect the logs to be there (in [ProgramFilesFolder]) because they've always been there before" is a legitimate point. So...
...in [ProgramFilesFolder]MyCompanyName, create a shortcut named Logs to the real Logs folder, which is located somewhere else that is UAC-compatible and ACL-safe. The shortcut gets "installed" just like any other "program" file, is read-only, and is accessible to anyone who can run the program itself.
Suits?
I find that the argument that has worked best for this topic is "Vista will come and get you". If you explain to people that a lot of the things that "used to be fine" will trigger new and "interesting" problems in Vista because Microsoft is running a tighter ship, then that actually seems to hit home and u get a "yes, I suppose we should start preparing for that" vibe going.
Personally I am amazed that Microsoft hasn't come up with a better way to separate the basic content of a computer: binaries, configuration files (which can be user and machine level) and user data. I think we will see major changes in terms of how storage is done once NTFS, FAT and all the file system dinosaurs get replaced by MSSQL as storage system (which will create a whole range of new problems of course).
Its a very good practice to separate code and data. I would like to see a operating system that provide separate storage for code and data; may be separate partitions. and application can only write to data partition. writing to code partition is allowed only for special applications like installer or os itself. it would also secure system from viruses writing to codes of installed applications.
Post a Comment