Chdir problem

[Kenneth Brody]

Fairlight wrote:
[...]
> > Use opendir/@dirlist/closedir to read everything in the "c:/edata/Geis-A"
> > directory.  You can then build the fill path and use EXISTS() to see if the
> > file "c:/edata/Geis-A/"{name{"/ANSI/997/all/997.rpt" exists.  If it does,
> > you can then use @FSTAT[] to check the modification date.
> 
> Problem being, what if someone sticks a file in c:/edata/Geis-A instead of
> a directory?  What -exactly- will fP's opendir do?  Based on opendir(3),
> which I assume you're basically wrapping, they return a NULL.  What does fP
> do in this context?

We're only doing the opendir on the Geis-A directory, since the OP says
that the next part os the only variant.  However, if you were to try to
opendir() something that's not a directory, I would expect it to fail
and return the error code.  Under *nix, I would expect an ENOTDIR error
to be returned.  I'm not sure what the Windows error is.

> For that matter, what does fP's open() do if you try to open a directory?
> :)  I've seen a variety of behaviour.  vim will actually give you the list
> of files in the directory to edit, for example.

It depends on the O/S.  Some systems allow directories to be opened for
read-only mode.  Others will fail with EISDIR.

> Is there any way in fP to safely distinguish between file and directory?  I
> actually need to know this for something someone wants written--technically
> I could live without it and mandate, "No directories shall be present!" in
> my case, but it would be nice to be able to bullet-proof it the way i'm
> used to doing things.

I suppose EXISTS( pathname { "/." ) should succeed only if "pathname" is a
directory that you can acccess.

> And besides that, files get dumped in weird places sometimes.  Someone
> could dump a core in a directory where you expect only directories and it
> wouldn't even be intentional, and half the people out there would never
> even notice they'd done it.  That's actually being generous, probably.
> So I really don't like to make assumptions about what will and won't be
> present.

That's why you have PFDIRFILTER=ON to make sure that only directories are
shown in the list of filePro filenames.  (Note that it's OFF by default,
as some systems can be extremely slow if there are a significant number
of files/directories in the filepro directory.  I saw once case where if
you had a few hundred files, it would take 10-15 seconds to display the
list of filenames.)

-- 
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody        | www.hvcomputer.com |                             |
| kenbrody/at\spamcop.net | www.fptech.com     | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+