43

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:

  1. The program directory
  2. The user's desktop
  3. 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.

Community
  • 1
  • 1
Darcy Casselman
  • 2,574
  • 3
  • 24
  • 26
  • What is the purpose of the log file? That could drive the answer. Who would look at it? Would it be looked at in most cases? Only looked at if there's a problem? – noctonura Oct 15 '09 at 15:57
  • The tool is a database upgrade tool and it does a bunch of things to your database. The log shows everything it does, including errors. Most users probably only look at it in case of error, but we expect a lot of DBAs will want to know exactly what was done. So they'll want to go find the log and look at it. – Darcy Casselman Oct 15 '09 at 17:31
  • See also [this question](http://stackoverflow.com/questions/269893/best-place-to-store-config-files-and-log-files-on-windows-for-my-program) – Dimitri C. Aug 16 '10 at 13:45

7 Answers7

24

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.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • 2
    The AppData folder is the best place, but it does need a link from the program or start menu to allow easy access, even for admin type people. Why don't you just pop up the log file at the end of the run, or open an explorer window for the AppData folder? The ProgramFiles folder is wrong, Vista onwards sees that as read only unless you are an installer program. The user documents and desktop are bad choices, they should be left clear for documents the user has created (typed, downloaded) not logs. – Martin Oct 15 '09 at 15:32
  • 1
    Could you please elaborate on this answer? What would I name the log folder that I'm creating in Application Data? The name of my app? The organization name? What is the Windows convention? – Thunderforge Jul 13 '17 at 17:33
  • @Thunderforge it's obviously pretty arbitrary. On my Windows 7 system I see Microsoft is using `AppData\*\Microsoft\(app name)`, with perhaps subdirectories under that. – Mark Ransom Jul 13 '17 at 17:44
  • Good, so it follows the `organization\app` convention most other platforms use. What does the `*` mean? – Thunderforge Jul 13 '17 at 17:45
  • 3
    @Thunderforge there are 3 subdirectories under `AppData`: `Local`, `LocalLow`, and `Roaming`. Microsoft has entries under all 3, although I've only ever used `Local` myself. – Mark Ransom Jul 13 '17 at 17:47
11

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 ...

GoJiTa972
  • 121
  • 6
  • 1
    Good point. Something to keep in mind when dumping stuff in AppData. – Darcy Casselman Oct 15 '09 at 18:05
  • 21
    Consider %LOCALAPPDATA% - the non-roaming equivalent. – Disillusioned Oct 05 '11 at 11:14
  • 4
    I wouldn't store a log file on a TEMP folder. Files in TEMP are meant to be temporary and can be deleted at any time. The purpose of a log is to stay there until something bad happens or you need to consult it. You don't want your log to be randomly deleted by the system and be gone the day you need it. If the logs get too big you either need to setup your application to use a circular log or delete older files after some time. – Maxime Sep 26 '17 at 03:03
8

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)

DmitryK
  • 5,542
  • 1
  • 22
  • 32
  • 3
    Using anything under the Program Directory is a bad idea because that is shared amongst any user who uses the machine. Would you then grant anybody read/write permission to this DebugLog directory? Then you have security issues, different users overwriting eachothers' log files, etc.... Your #3 is the right answer IMHO. – noctonura Oct 15 '09 at 15:55
  • You are quite right. In this particular case though (debug logging) a subdirectory is acceptable in my view. (this is not a standard way of using this software, but rather an exception). So it is OK to allow debugging log to be stored in a Debug subdirectory. Debugging logs should be created with unique names to prevent overwriting. – DmitryK Oct 16 '09 at 12:33
  • How you'll what folder user is creating in Program Files when he runs setup. – Imran Rizvi Sep 11 '12 at 07:18
3

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.

James
  • 80,725
  • 18
  • 167
  • 237
  • 5
    Good point, but I would discourage recording things into My Documents or the Desktop - those are the user's places and I don't think applications should write anything to them unless directed to do so by the user. – Thomas Owens Oct 15 '09 at 15:05
  • It isn't uncommon for applications (by default) to save items in the MyDocuments folder e.g. templates. Visual Studio does this as does Delphi. – James Oct 15 '09 at 15:10
  • I personally get annoyed when things save things to My Documents, but that's me. One of the arguments against AppData is that it's not easily "discoverable" by users, so My Documents might be better... – Darcy Casselman Oct 15 '09 at 15:16
  • Don't use the application folder when writing Web Applications. For example for IIS this will cause application pool recycling and losing session! – cah1r Apr 17 '15 at 07:42
2

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.

Foxfire
  • 5,675
  • 21
  • 29
1

Windows Temp Folder

Zote
  • 5,343
  • 5
  • 41
  • 43
  • 8
    Why? Who would ever look for a log file there. It's not a temporary file, IMO. – Thomas Owens Oct 15 '09 at 15:03
  • 2
    He told "an application that's only likely to be run once by one user" with this information I think that is an temporary log and temporary application. – Zote Oct 15 '09 at 18:59
0

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%.

cdiggins
  • 17,602
  • 7
  • 105
  • 102