Re: Opening a file - File Open Dialog spoils future code

new topic     » goto parent     » topic index » view thread      » older message » newer message

CChris wrote:
> 
> All right, I should have checked first, but the bottom line is the same:
> never use current_dir() under Windows. Here is what I found on MSDN:
> <quote>
> The directory at the end of the active path is called the current
> directory; it is the directory in which the active application started,
> unless explicitly changed. An application can determine which directory
> is current by calling the GetCurrentDirectory function.
> 
> An application can change the current directory by calling the
> SetCurrentDirectory function.
> </quote>

I don't see how your conclusion follows from this.  Perhaps we could/should
alter the behavior of the interpreter under windows to call the win32
functions instead of the c library.

> I have recently wondered why I wasn't finding ex.err after a program crash.
> Searching ex.err on my machine reported 9 different directories, some of
> which I'd havd never thought about. Since ex.err is created using
> open("ex.err","w"), I consider the "current directory" to be undefined for
> practical use: it is defined, but as something volatile (what is the active
> application on a multiprocess platform?). I'd go as far as recommending to
> drop support of current_dir() and chdir() under Windows.

I think you've misunderstood what MSDN was saying.  You can change the current
dir for your app, not for the system.  It's only volatile in that you can
change it.  It shouldn't change based on other processes.

I have been annoyed at times by where ex.err is created.  Perhaps that's
another enhancement to be considered.  But I don't think that it means that
we should abandon current_dir/chdir.

Matt

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu