stat ino, nlink fields not set

Logged In: YES
user_id=32170

Added first attempt at a patch.

Vince.

Logged In: YES
user_id=32170

And here's a better patch with tests.

second patch

Logged In: YES
user_id=219610

Make sure st_ino is at least defined as an unsigned. I don't know where
you're getting your definition of struct stat from, but the one from MS's
headers and the one in MSYS default st_ino to short, and both
nFileIndexHigh and nFileIndexLow are DWORDs. You can imagine all
the collisions you can get by casting a quad word to a short ;-)

The other thing you guys might want to consider (although it might be
too much work and you might just decide to punt on it) is that you can
actually fake the st_nlink for directories and have it behave just like
Unix. I wrote a little proc that goes something like:

int
dirEntries(const char *dir)
{
WIN32_FIND_DATA f;
HANDLE h;
char buf[MAXPATH];
int len, count = 0;

strcpy(buf, dir);
len = strlen(buf);
if (len == 0 || buf[len - 1] == '\\' || buf[len - 1] == '/') {
strcat(buf, "*");
} else {
strcat(buf, "/*");
}

if ((h = FindFirstFileA(buf, &f)) == INVALID_HANDLE_VALUE) return
(0);
count++;
while (FindNextFileA(h &f)) {
if (f.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) count++;
}
FindClose(h);
return (count);
}

You might want to tweak it to conform to Tcl-style and not use the *A
API which is just for ASCII and doesn't handle Unicode. As I said, I
don't know how useful this would be... it allows some optimizations
when walking directory structures, but I don't know if anyone else uses
those...

Logged In: YES
user_id=32170

'st_ino' will come from whatever the compile environment
sys/stat.h or sys/types.h says, so, as you correctly point
out, it's "unsigned short". Nothing Tcl can do about that, I
believe.

I don't know how 'nlink' is defined on unix, but no 'man
stat' that I've found talks about nlink for directories as
the number of files within in, so I'd be interested in a
clear definition (does it include subdirs, symlinks?).

Logged In: YES
user_id=219610

There should be a warning in the release notes or somewhere that st_ino
can have collisions on Windows and should then not be used for
determining whether a file is the same as another. A typical idiom (in C)
for determining if two files are links to the same file is:

if (stat(filea, &sa) || stat(fileb, &sb)) return (error);
if ((sa.st_ino == sb.st_ino) && (sa.st_dev == sb.st_dev) &&
sa.st_nlink >= 2)) return (same);

In Tcl it would be more verbose, but it would follow the same pattern.
This is dangerous because on Windows that code could very well say
yeah, they're the same when in fact they are not. Obviously, the current
code just returns 0 for st_ino, so it would fail that test...

In Unix, the '.' and '..' directories, are links to self and parent
respectively. So if you create an empty directory, it will have 2 links
(self, and the link from the parent directory). If the directory doesn't have
any subdirectories, it will have 2 links (same as before). If you create a
subdirectory, that subdirectory also has . (self) and .. (to directory), so
now, our directory will have 3 links.

$ mkdir foobar
$ ls -lad foobar
drwxr-xr-x 2 ob ob 68 Oct 14 10:34 foobar
$ mkdir foobar/baz
$ ls -lad foobar
drwxr-xr-x 3 ob ob 102 Oct 14 10:34 foobar
$

A common optimization for determining whether you have to recourse
into a directory or not, is to use hard links to see if the directory has any
subdirectories or not... but I have to admit it's kind of a special case...
maybe not worth implementing.

Logged In: YES
user_id=32170

Committed fix to cvs head.