win32utils.get_home_location used for .bzr.log is incorrect

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.

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

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

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

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.

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.