Current directory and current drive. Is there such a thing?

[xlucas]

Hi, guys. I have some confusion about the concepts of current directory and current drive. It goes as follows.

In the DOS times, it was all very simple. At all times, there was a current drive and each available drive had a current directory. When you were at the command line, these two were obvious. Once you were running a program, they were not visible, but they remained very real and when you exited the program, whatever drive and directory were current at that time would display at the command prompt.

With GNU/Linux and Windows, this is less clear to me. If you open two console windows, you can navigate to different directories and when you execute a program, it appears to report the current path as the one you have in that particular window. Then some philosophical questions come to my mind, such as... "What is the current path when you don't have any console window open?" or "Does it make any sense to refer to the current directory of a process that's running in another window from a process that's running on this one?" or more drastically "Perhaps current directories and drives don't exist anymore?"

Clearly, something that can more or less be called a "current directory" does exist, because FreeBasic has a CurDir function. I think this path is always absolute, so I could just obtain the "current drive" from the first two letters of this string if running Windows. But then, how do I obtain the current directory of another drive?

And I have another doubt. Since my OS is GNU/Linux and I don't have Windows, I can't easily test this. I assume that if I use the ChDir statement with an absolute path in Windows, it will change both the current drive and current directory, but if I use a relative path, it will only change the current directory, but remain in the same drive. Is this correct? And what if I want to change to another drive's current directory? Can I do ChDir "D:" or do I need to do something like ChDir "D:."?

Thanks!!

[jj2007]

A Current Directory for each drive?

Originally in MS-DOS, each drive had its own current directory, for complex historical reasons.

Now in Win32, there is one global current directory, but at the command line the appearance is still maintained that each drive has its own current directory, this is a fake-out by cmd.exe.
The location for each drive is stored using the undocumented environment variables =A:, =B:, =C: etc.

This is Windows, and basically it means NO, you cannot change or retrieve the current folder of another drive programmatically, simply because it doesn't exist. It works only from a DOS prompt, using e.g. echo %=C:%

[Vortex]

Hi xlucas,

A quick test on Windows :

Code: Select all

#include "windows.bi"

Dim As ZString * MAX_PATH+1 Buffer

GetCurrentDirectory(MAX_PATH+1 , @Buffer)

Print "Current directory = " & buffer

[dodicat]

In windows it seems curdir defaults to a current drive.

Code: Select all

#include "crt.bi"
Declare Function stats Cdecl Alias "_stat"(As zstring Ptr,As Any Ptr) As Integer


Function isfolder(path As zstring Ptr) As Long
    #define S_ISDIR(m)   (((m) And &hF000) = &h4000)
    Dim As stat statbuf
    If (stats(path, @statbuf) <> 0) Then Return 0
    Return S_ISDIR(statbuf.st_mode)
End Function



print isfolder(curdir)
print

dim as string required="f:\"

if isfolder(required) then 
     
     if chdir(required)=0 then
            print "curdir"
      print curdir
else
      print "exists but not available"
      end if
else
      print "curdir not found, only drive "
      shell "echo %CD:~0,3%"
      print "and curdir"
      print curdir
      end if

sleep



 

[speedfixer]

Maybe part of the doubt comes from understanding the 'directory/drive/user' concepts.

In an OS where users are allowed access to multi-thread capabilities, the thread delivered by the OS supplies the thread with an environment, typically a copy of the parent - AT THE TIME OF CREATION. This environment can change during the execution of the thread, including its current unprefixed directory/folder. Let's call this the 'current' directory.

Multiple threads, multiple apparent 'current' directories.

Each new console is a separated thread, with its own environment. Obviously, they don't have to start at the users home directory.

With the old DOS environment - generally, the user was not allowed to spawn threads. Only 1 environment was possible to the user. (Gross generality, but you get the picture.)

Newer OS's don't have that limitation.

Next: Linux/etc. - at the user application level - do not use a 'drive' concept: EVERYTHING is a file. There are different kinds of files: character, block, more. These would only be addressed by the correct functions that would know what type of 'file' it is.

A 'directory' is a file that catelogs disk locations of where other files and 'directories' live in a file system structure. The file system MAY be a disk, or a collection of disks/devices/location accesses (network share address, for example.)

A new console session is a 'file' expected to be accessed in a particular manner: streaming I/O - with protocol rules of how to talk to it. It MAY have rules about how to do more: display control, for example. But that is a function/expectation of the program that will 'talk' with the 'file': X11, a term/console program, the FB graphics library.

For this current dir/current drive purposes in Linux:

Each program running can be in its own environment, originating with its own 'current' directory that the program can change during its execution.

david

[caseih]

Note that on Windows, there are a number of different ways to refer to paths with drive letters: https://docs.microsoft.com/en-us/dotnet ... th-formats

For example
C:\myfile
\\.\C:\myfile
\\.\UNC\LOCALHOST\c$\myfile

So really drive letters are just a path in reality. There's no such thing as "the current drive" outside of the cmd.exe context.

[caseih]

As far as what the current working directory is when you start a program from a GUI and not from a shell on Linux, the answer is that it inherits whatever working directory was set in the parent process. And of course the working directory can be set at any time with the crt call setcwd().

[xlucas]

Oh! So basically, the most drastic way of seeing it was in fact the closest to reality: current directory and drive don't really exist in the sense they did in DOS and the only thing that does exist is the working directory, that is, the directory relative to which relative paths are expanded into absolute paths and this can change from process to process. Thank you, guys. It really makes more sense to me now!

Now, specifically about FreeBasic behaviour... In GNU/Linux, there's no problem because there're no drives, but how does the working directory of a process change when you execute these sentences?

1 - ChDir "D:"
2 - ChDir "D:."
3 - ChDir "D:\"

In DOS, I would expect the first and second ones to switch to drive D:, preserving the current directory for that drive, but such thing doesn't exist in Windows nowadays. Another logical result would be for the first one to result in an error like "invalid path" and the second one to do nothing, which would be consistent with the execution of the "CD" command in DOS. For the third one, I would expect FreeBasic would switch to drive D: and to the root directory of that drive, but again, if we want to be consistent with DOS's "CD" command, this should change the current directory of drive D: to root, but remain on the same current drive.

The thing is, if ChDir in FreeBasic behaves in Windows the way I expect, then it means I know now how to do the things I want. On the other hand, if ChDir is consistent with DOS's "CD" command, then I don't know how to cause the drive in the current working directory for the current process to change. How would I do that?

[caseih]

In CMD.exe, it behaves as you expect, just like it did in DOS. Inside of programs, I'm not sure there was ever actually a current directory maintained per drive letter. Pretty sure that was just a feature of command.com.

[counting_pine]

I did a quick test on Win10, and the program seems happy to remember the Current Directory across multiple drives.
chdir("L:") changes to that drive's current directory, chdir("L:\") changes to the root of that drive.

Code: Select all

sub test(path as string)
  chdir(path)
  print "cd " & path, "-> " & curdir()
end sub

var path1 = "C:\Windows"
var path2 = "D:\Test"

var let1  = left(path1, 2), let2  = left(path2, 2) '' L:
var root1 = left(path1, 3), root2 = left(path2, 3) '' L:\

test root1
test path1
test let1
test root1
test let1
test path1

test root2
test path2
test let2

test let1
test let2

Code: Select all

cd C:\        -> C:\
cd C:\Windows -> C:\Windows
cd C:         -> C:\Windows
cd C:\        -> C:\
cd C:         -> C:\
cd C:\Windows -> C:\Windows
cd D:\        -> D:\
cd D:\Test    -> D:\Test
cd D:         -> D:\Test
cd C:         -> C:\Windows
cd D:         -> D:\Test

[xlucas]

Perfect! That settles it completely. Thank you so much!

[adeyblue]

I did a quick test on Win10, and the program seems happy to remember the Current Directory across multiple drives.
chdir("L:") changes to that drive's current directory, chdir("L:\") changes to the root of that drive.

That's what caseih mentioned above, but nowadays it's the CRT that keeps per-drive-current-directories rather than a specific cmd.exe thing, so FB and every other app can benefit from it (as long as you use chdir).

For completeness, if you don't use chdir and use the Windows API SetCurrentDirectory instead, then you get these results

Code: Select all

cd C:\ -> C:\
cd C:\Windows -> C:\Windows
cd C: -> C:\Windows
cd C:\ -> C:\
cd C: -> C:\
cd C:\Windows -> C:\Windows
cd T:\ -> T:\
cd T:\temp -> T:\temp
cd T: -> T:\temp
cd C: -> C:\
cd T: -> T:\

[caseih]

That's what caseih mentioned above

I had asserted that the drive letter is simply part of the path and that the current directory would contain both parts, meaning that windows would not maintain a per-drive current directory. @counting_pine demonstrated that I am incorrect in that assertion.

So if you use SetCurrentDirectory, it appears to sometimes store per-drive current directory and not other times? The last few lines of output are unexpected to me, given what you've said about windows storing the current directory per drive. Why does chdir to T: bring up T:\temp and then two lines later chdir to T: goes to T:\? What am I missing?

[jj2007]

I had a suspicion that SetCurrentDirectory would create a registry entry, because Windows registers every single irrelevant "event" somewhere, but nope, it doesn't. Strange.

[counting_pine]

Why does chdir to T: bring up T:\temp and then two lines later chdir to T: goes to T:\? What am I missing?

That’s probably a mistake, I made some changes manually. I’ll check in a bit..

EDIT: Sorry, I confused adeyblue's output for mine.