[Issue 3848] functions in std.file don't take symbolic links into account

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Feb 26 00:33:00 PST 2010


http://d.puremagic.com/issues/show_bug.cgi?id=3848


Jonathan M Davis <jmdavisProg at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #572 is|0                           |1
           obsolete|                            |


--- Comment #4 from Jonathan M Davis <jmdavisProg at gmail.com> 2010-02-26 00:32:57 PST ---
Created an attachment (id=573)
Next attempt at fixing problem.

Okay. I tried to fix this more cleanly this time. The result is that DirEntry
has changed a fair bit, but now isdir() and isfile() use stat rather than
lstat, and you can now get a DirEntry for a specific file without getting all
the DirEntries for a directory. I don't know whether it will be to your liking,
and I have not tested the Windows code at all, but from the testing I did of
the linux code, it appears to work (though it could always use more unittests).

By making DirEntry as lazy/efficient as possible and making it possible to get
one for any file, it should fix the efficiency issue of calling both stat and
lstat as much as is possible (though it would still be nice if there were a
posix function which did stat but also told you whether it was a symlink).

There are also versions of isdir(), isfile(), and issymlink() which take an
attributes (uint) value to make them the attributes values easier to use and
facilitate rmdirRecursive() only calling lstat. I didn't add any for block
devices and such, but perhaps they would be good to add as well.

DirEntry is using properties now with its member variables being private,
allowing for guarantees as to the state of its members. I don't know whether
you'd consider that a problem or not, but I think that it's cleaner.

I have attached the updated std.file.d.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list