D 2017-06-18T01:02:07.209
L Tcl\sfs\stesting
N text/plain
P 06a5970dac08f2c8983fd7d07c47e97b4277e82f
U imdave
W 1801
Files
=====

simplefs.c

The most stripped down Tcl FS that I could make. It tests the 'cd' command.
It does virtually no checking but should suffice as long as one does not 
deliberately break it.

Compile (on windows) with:

gcc -o simplefs simplefs.c -IC:/Progra~1/Tcl/include \
    -LC:/Progra~1/Tcl/lib -ltcl86


winvols.c

This is the code that Tcl uses to create the windows file system "volumes".
It shows that Tcl uses "C:/", "D:/", etc.
This (and the code in generic/tclTest.c) tells me that my volume name "zvfs:/"
should be valid.

What I'm trying to figure out
=============================

With tclsh, I can do:

% cd d:
% pwd
D:/
% cd msys64
% pwd
D:/msys64
% cd home
% pwd
D:/msys64/home
% cd ..
% pwd
D:/msys64
% cd ..
% pwd
D:/
% cd ..
% pwd
D:/


With my simplefs test program, I (used to) get:

% cd d:
% pwd
D:/
% cd zvfs:/
% pwd
zvfs:/
% cd dir
% pwd
zvfs:/dir
% cd another
% pwd
zvfs:/dir/another
% cd ..
% pwd
zvfs:/dir
% cd ..
% pwd
zvfs:

What happened to the root directory '/'?
From here on -- until the next "cd zvfs:/" -- Tcl gets messed up

Perhaps a related issue. On windows:

% cd d:
% pwd
D:/

With my fs:

% cd zvfs:
% pwd
D:/

Even though I've told Tcl that the cd is valid, it is rejected. Why does not
Tcl return "zvfs:/" as the pwd?

Update: I've added a FSNormalizePathProc() to detect and correct the bogus path. This is not a real fix.

Update 2: Attempting a "cd zvfs:/; cd /" I found Tcl deriving the path "zv/".
This is again due to Tcl not handling volume relative fs but assuming that
all such fs are windows. (The "zv/" comes from Tcl assuming the cwd is
"<drive>:" so "zv" is appended with "/". This can be fixed in FSNormalizePathProc
but is again a kludge.
Z 981654e76acb2e2cb27d4866ee647fa6