in reply to Re: Testing for a directory handle
in thread Testing for a directory handle

On *nix machines it shows the "." and ".." entries. I'm not sure how that works on MSWin. I've left it in as a potential edge case.

Well, as usual for Microsoft software: Don't expect consistent behaviour. Most directories have the . and .. entries. For the root directory of any drive, it heavily depends on the drive type. Some root directories have the . and .. entries, others don't. See Re^6: readdir() on a sysopen() handle? for details.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^3: Testing for a directory handle
by kcott (Archbishop) on Jan 31, 2018 at 02:27 UTC

    Thanks for the additional information regarding this. It doesn't affect me personally (either at work or home) at the moment, and probably won't do in the forseeable future; however, for those working with the MSWin filesystem, this could be important.

    I suppose the real issue is how this might affect telldir in the context of the code I posted. I'm not in a position to test this but I'll attempt to paraphrase in *nix parlance. Given a truly empty directory (root or otherwise), e.g.

    $ ls -al fred ls: cannot access 'fred': No such file or directory $ mkdir fred $

    Where a listing showed

    $ ls -al fred total 0 $

    instead of

    $ ls -al fred total 0 drwxr-xr-x 2 ken staff 68 Jan 31 12:57 . drwxr-xr-x 18 ken staff 612 Jan 31 12:57 .. $

    How would the "eh" handle be reported? Just to be clear, that's the one I showed as:

    eh is a dirhandle       # eh = dirhandle to "pm_1208018_test_dir_empty"

    If someone could test that and report their findings, it could provide useful information to anyone wanting to use this technique in the future.

    — Ken