I want a an app that is "self-contained" (I don't know if i use the right word. "putting the app into trash bin will remove everything" is what I meant). But the app requires some resources to run. I usually put those resources into a folder. I want to move those resources into the App folder ( package contents). Can I do that? Is it a good practice to do that?
When I test the app directly running from Xcode, the App runs fine. But if i run it from finder, the app will say fails to create resources folder because permission denied. I checked the app's folder permission - User(me) has read/write access. I am wondering what is causing this different behavior.
The last option is to use Application Support folder, but I don't want to leave trails when user deletes the app.
Can someone help me out here?
Applications live in the directory /Applications, where users don't generally have write access. Requiring an app to have write permission in system folders is extremely bad practice.
Runtime files should live in ~/Library/Application Support. While that folder tends to accumulate some cruft, unless your application leaves behind really large files, that shouldn't be a problem.
If you want your application to be self-contained, it needs to come with all the files it needs from the get-go, and not write anything to disk.
Related
I’m writing an application that should save user specific data into AppData. This application has an installer. Now I’m not sure, what is the best way to provide the folders in AppData.
Should the installer create (and delete) the folders, or should the application itself create (but probably never delete) the folders.
Also, if multiple user on the same computer use the app, the folders probably doesn’t exist, if another user installed the application.
I didn’t found anything that really explained this to me.
Thanks in advance.
I'll answer for Windows Installer, MSI files, and basically you shouldn't need to worry about it in the installer; just install files to their required locations, and the folder will be created automatically and removed at uninstall if it's empty.
In addition to Phil's correct answer:
If the files from the AppData folders used by your application are created only by the application, at run time, there is no need to configure the installer to create the empty folders. Those folders will be created the moment your app writes down the files.
Also, even if your installer is creating the folder, on uninstall it will not remove if in that folder are files created by the application. Windows Installer keeps track (should do it in a correctly configured package) of every file it installs and only removes the ones it installed (by default, it can be configured to force remove a folder and files which it did not install).
Regarding other users of the app. In this scenario, the simplest method is to use your application for creating the initial default files in the AppData folder, at the first launch of the app for each user.
If you need to install files to AppData from your installer then you could try one of the following approaches. These techniques can be applied with any setup authoring tool that can create MSI packages.
I am trying to get my app submitted to the mac app store and I am having a bit of a design problem. Our app is an authoring tool and comes bundled with many projects created with the tool. Before the time of the app store, we would ship our app as an .img file which contianed a project directory and our app. Since I am only going to be submitting the .app file to the app store
with my app I am wondering where I should but the projects directory.
Initially I tried to put the projects directory inside of the bundle but this will not work because it is possible for the user to make changes to projects which might add new files to the project directory and this would make the sandboxing unhappy and mark the app as invalid.
What is the correct place to store such resources? I assume they should go inside the container? If so, what would be an elagent way to deploy this projects directory? Since we do not have installers in Apple land what would be the best place to deploy this projects directory? Do I just need to check on app launch if the projects are present and if not copy them from the bundle? This seems wrong.
Do I just need to check on app launch of the projects are present and if not copy them from the bundle?
Actually, this sounds right to me. As you said, the user cannot change/add any files in the app bundle. If you have resources there that the user needs to interact with, I would copy them to the ~/Library/Application Support/MyApp/ folder when they are needed. The user can then interact with the files from that location. (When sandboxed they go into a different but related location.)
I don't really know what your app does, but it would also seem like a possibly useful feature to "reset" the project files/folders back to a starting state. So copying the files in this way would allow for that kind of behavior as well.
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.
I am developing an application in cocoa which needs to copy a set of files to the system folder. When copying files to system folder I am getting a "Permission denied " error message . How can I resolve this problem.
Please any one help me...
Thanks in advance
It shouldn't be necessary to put anything in /System, and it's probably not a good idea anyway, as it could get wiped out by a system update. My guess is that whatever you're looking to do should be possible by some other means, e.g. using /Library or ~/Library.
Mac OS X uses a system of authorization that prevent application to copy files in system locations without warning. That's why you have to enter your credentials when installing a framework for example.
If you want to perform privileged operations in your application, I suggest you to read the Authorization Services Programming Guide and especially the Scenarios chapter: it will help you to decide how to do the file copy.
Use PackageMaker to make a proper Installer package, like I suggested on your previous question.
Where would be the best "standard" place to put an application's debug log file in a Windows user environment?
In this particular case, it is an application that is run once and could go wrong. It will be run by system administrator types who may need to inspect the log after the application is run. Everytime the application is run, a new log file is created.
Options that have been floated so far include:
The program directory
The user's desktop
The user's local Application Data directory.
I have my favourite, but I wondered what the SO consensus was.
Note: this is similar to this question, but we're dealing with an application that's only likely to be run once by one user.
The Application Data directory would seem to be the perfect place, but it's an area that is nearly invisible. You need to give your users an easy way to get to it.
Have your installation script create a Log folder in the Application Data area for your program, and include a link to the folder in your Start menu.
In the organization I work for we use the (%TEMP% or %TMP%)\CompanyOrProductName\Logs directory
Using %APPDATA% may be problematic with roaming profiles if the logs are numerous or huge : it slows their login process ...
1.The program directory <- not good. Ideally you will only have RX permissions on this folder.
2.The user's desktop <- technically can be done, but I don't like this idea. Polluting desktop... I, as a user, don't like it.
3.The user's local Application Data directory. <- better
My preference is a subdirectory under the program directory (with a clear name like "DebugLog" or something similar). Permissions on that subdirectory should allow creating and writing files ("Change" will be fine)
The "standard" place for the log would be the AppData directory. However, really its up to you where you want to store them. As they are administrator (power users) then there should be no problems storing the logs in the same directory as the application being run. Even in the MyDocuments of the user would be a good shout.
If you EXPECT something to go wrong put it in the user's local Application Data directory.
If you don't and just want to log anyways I might think about really using the temp directory. The reasoning for this is simple. If the application is only run once you will leave trash in the Application Data directory otherwise that nobody will ever need again. In the temp you have at least the CHANCE that it's going to be cleaned up later.
BTW: IMHO the best would be not not create the log AS A FILE at all (log to memory) until something goes wrong. Then you can still offer a dialog where the user selects where to save the log.
Windows Temp Folder
Assuming you want to keep log files around a significant amount of time and they are intended to be used, read I would put the log file in a sub-folder of the user's local application data folder, accessible from windows explorer by typing %localappdata%.
If they are temporary log files, only to be used in the event of system diagnostics then you should put them in the temporary folder, accessible from windows explorer %temp%.