win32utils.get_home_location used for .bzr.log is incorrect

Bug #240550 reported by Mark Hammond on 2008-06-16
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar
Low
Unassigned
Breezy
Low
Martin Packman

Bug Description

The above function returns the location of "My Documents" - eg:

>>> from bzrlib.win32utils import get_home_location
>>> get_home_location()
u'D:\\Documents and Settings\\skip\\My Documents'
>>>

I note that this is used to locate the log file. The end result is that our log file ends up in My Documents, which is not appropriate ("My Documents" is a folder for documents created directly by the user - if every software package put its log there, obviously it would be useless for the user. It only *seems* to be appropriate now as bzr is one of the few software packages rude enough to use it this way.)

I'd suggest that either CSIDL_APPDATA or CSIDL_LOCAL_APPDATA be used (the former location "roams" when the user logs into a different machine, while the latter does not - eg, by default, %TEMP% is under the latter.

Alternatively, if it is decided "My documents" really is where we want to put the log file, this function should be renamed - "my documents" should not generally be considered the "home" directory on Win32. get_documents_location() would seem a reasonable name (as that is indeed what it returns), or maybe simply "get_log_location()" if that is really all it will be used for (but I doubt that)

Related branches

Alexander Belchenko (bialix) wrote :

Initially we are used os.expand('~/.bzr.log') regardless of platform. But this will tend to place log either to the root of drive C: or to C:\Documents and Settings\USERNAME depends on HOMEDRIVE and HOMEPATH environment variables. I saw corresponding bug report in Python, but it still non-fixed.

I chose My Documents folder because it much easier to say people when they come with troubles or bug reports: "show me the last part of .bzr.log in your My Documents folder". Just to easy locate this file. This is answer on question "why we use wrong My Documents."

Of course now location of this file shown in output of bzr --version. But when I switch to My Documents it was not. This is my story.

Mark Hammond (mhammond) wrote :

Thanks for the update. I think it is true to say that if every app did what bzr does, users would *not* be happy, so would you have any objection to using SHGetSpecialFolderPath() to locate a more appropriate directory?

Mark Hammond пишет:
> Thanks for the update. I think it is true to say that if every app did
> what bzr does, users would *not* be happy, so would you have any
> objection to using SHGetSpecialFolderPath() to locate a more appropriate
> directory?
>
I no more working on bzr, so I have no objections at all.
And I think you're much more experienced win32 developer than me,
so I'm leaning to trust to your decisions almost absolutely.
Thank you for catching this and pointing at wrong code.

I agree that friendly apps should probably not be populating My Documents. To date, it has been a file we have requested from users, and that makes it difficult to use APPDATA. AIUI, the default behavior is to have all APPDATA directories hidden to users. Which makes it hard for them to find the file to include it in bug reports.

Otherwise, I would say that the best location would actually be in the config directory. ~/.bzr.log is a bit of a hang-over, and I think ~/.bazaar/log would be better. On win32, that would be $APPDATA/Bazaar/2.0/log (I would be fine dropping the 2.0).
Also, .bzr.log should probably not be in the roaming profile. It can grow to a couple megabytes (before we roll it over to .old and start a new log file). Though if a single process writes 100MB the file can grow without bound. (We only roll it on first access.)

If we do end up putting it somewhere that is hard to reach, we probably should provide a command for grabbing it for the user (which also needs to be careful, as running a bzr command might just roll the log file and hide everything that we want them to send.)

Changed in bzr:
importance: Undecided → Low
status: New → Triaged
Alexander Belchenko (bialix) wrote :

> On win32, that would be $APPDATA/Bazaar/2.0/log (I would be fine dropping the 2.0).

John, it was your idea (about bazaar/2.0) initially. But -- yes, please. This 2.0 is just redundant and makes life of some windows users (like me) a bit harder.

Mark Hammond (mhammond) wrote :

Thanks for the comments: when you say "grabbing it for the user", what did you have in mind? How about we install a shortcut to notepad opening the log file on the start menu? Sounds simple and effective...

Mark Hammond (mhammond) wrote :

oops - I also meant to ask a slightly philosophical question: do we prefer to use the (eg) APPDATA environment variable, or the "shell" API functions with the equivalent CSIDL_* constants? While the environment variables will usually match what the API returns, there are pros-and-cons to both approaches; I'm inclined to say that as the API is the official way of getting these values, it wins, but a good argument can be made for allowing the values to be overridden in the environment.

Mark Hammond пишет:
> oops - I also meant to ask a slightly philosophical question: do we
> prefer to use the (eg) APPDATA environment variable, or the "shell" API
> functions with the equivalent CSIDL_* constants? While the environment
> variables will usually match what the API returns, there are pros-and-
> cons to both approaches; I'm inclined to say that as the API is the
> official way of getting these values, it wins, but a good argument can
> be made for allowing the values to be overridden in the environment.
>

Look at win32utils.get_appdata_location()

I believe that CSIDL_* is the *correct* win32 way of doing things. So I would use that. At least, that is what I found when I researched it a long time ago.

Martin Pool (mbp) on 2010-03-19
Changed in bzr:
status: Triaged → Confirmed
Martin Packman (gz) on 2012-02-01
tags: added: easy win32
summary: - bzrlib.win32utils.get_home_location incorrect
+ win32utils.get_home_location used for .bzr.log is incorrect
piersh (piersh) wrote :

is 4 years too short a time to expect a fix for this?

Bug #842996 is marked as a duplicate of this bug, but comments there add information not present here. Of primary interest is mention that BZR_LOG may be used as a workaround.

Another comment in #842996 mentions that BZR_LOG DOES NOT influence where tbzrcache.exe writes its log, but, at least with Bazaar 2.5.1 on Windows XP, setting the BZR_LOG environment variable DOES change where tbzrcache.exe writes log data - as confirmed by the presence of a log message "INFO: tbzrcache running..." in the log file at a new location specified via BZR_LOG. When BZR_LOG was observed to impact tbzrcache.exe, BZR_LOG was set to a value like %APPDATA%\bazaar\.bzr.log using Start | Settings | Control Panel | System | Advanced | Environment Variables.

Jelmer Vernooij (jelmer) on 2017-11-09
tags: added: check-for-breezy
Martin Packman (gz) on 2019-06-16
Changed in brz:
status: New → In Progress
importance: Undecided → Low
assignee: nobody → Martin Packman (gz)
milestone: none → 3.1.0
Jelmer Vernooij (jelmer) on 2019-06-16
Changed in brz:
status: In Progress → Fix Committed
Jelmer Vernooij (jelmer) on 2019-06-25
Changed in brz:
status: Fix Committed → Fix Released
tags: removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers