On my linux system following code gives for any filesystem point:
0 0
result. At least on linux DirEntry can not distinguish between file and directory.
-----------------
import std.stdio;
import std.file;
void main(char[][] args) {
bool callback(DirEntry* de) {
writef(de.isfile, " ", de.isdir);
return true;
}
listdir(args[1], &callback);
}
Comment #1 by braddr — 2007-11-04T01:28:38Z
I can't reproduce this on my linux system. I'm going to need more information to be able to do anything with this report. I suggest copying the code from std/file.d into your test app (ie, create a standalone test case that doesn't need any (or at least fewer) imports). Add some debug code to inspect the data closer.
Make sense?
Comment #2 by aarti — 2007-11-04T16:26:47Z
After some researching it seems that in this structure (from import std.c.linux.linux):
struct dirent
{
uint d_ino; // this is int on some linuxes
off_t d_off;
ushort d_reclen;
ubyte d_type; // this field isn't there on some linuxes
char[256] d_name;
}
field d_type is not set by readdir method.
In the same time isdir & isfile free functions works properly.
I have fresh installation of Ubuntu Gutsy 7.10.
Comment #3 by aarti — 2007-11-04T16:29:15Z
Created attachment 201
test file with only few functions from std.file
Comment #4 by lutger.blijdestijn — 2008-10-07T05:59:44Z
Same problem here. The readdir docs say that the dirent.d_type field is a bsd extension, not part of the posix standard. The standalone isdir() and isfile() functions use stat, so they are fine (but more costly.)
This also breaks DirEntries in 2.0 and functions depending on it.
Comment #5 by andrei — 2010-09-25T17:39:04Z
Can't reproduce.
Comment #6 by issues.dlang — 2010-09-25T18:09:50Z
See also bug# 4929. Currently, on Linux/Posix, DirEntry use d_type from readdir to set its file type, and if you'll look at the man page for readdir, it specifically says that d_type is not supported by all file system types. DirEntry really should be using stat if d_type wasn't set properly. My patch in bug# 3848 makes it so that while it still uses d_type for the file type if it was set correctly, it uses stat instead of d_type if d_type is DT_UNKNOWN.
The only place that I'm sure that I've run into this problem (and consistently) is with /usr/share/zoneinfo, but I think that it's very nature makes it so that it's only going to fail under certain types of situations or on certain types of systems.