Le 01/09/2021 à 21:22, Greg Troxel a écrit :
Looking into the avc failure, I find
$ ogrinfo ogr/data/avc/testavc/testavc/
INFO: Open of `ogr/data/avc/testavc/testavc/'
using driver `AVCBin' successful.
1: ARC (Line String)
2: LAB (Point)
But if I leave off the trailing / I get a failure to find a driver. A
trailing slash on a directrory name seems odd to me, and usually the
result of completion.
Hum, I suspect you might hit a similar issue as the one for FreeBSD in
https://github.com/OSGeo/gdal/blob/a95e796f65b26379b0e5c699bacef29f7684f79f/gdal/gcore/gdalopeninfo.cpp#L216
where fopen("/some/dir", "rb") succeeds.
Can you test changing that with whatever define is appropriate to test
for your OS and submit the resulting patch ?
The comment about FreeBSD being odd seems strange to me, as POSIX has no
notion that fopen must fail when opening a directory for reading.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
As I read the spec, it is a violation to return NULL when the first
argument is a directory and the second is r or rb. A test program
succeeds in calling fopen on . with rb, on both NetBSD and macOS 10.13.
Perhaps I am misreading the POSIX spec.
It is not clear for me. There's a mention that opening a directory in
update mode should fail. But I can't see the point of succeeding in
read-only mode. You can't read anything.
But actually I do see that on my current Linux system too fopen(somedir,
"rb") works, but later in that function, we try to read some bytes from
it. If we don't manage to read a single byte, then we fallback
to a stat() to check the nature of the file. So I suspect that on your
OS and FreeBSD, the fread() does return some bytes, whereas the other OS
on which we regularly test, return 0.
I guess we might want to change the current test as #if
!(defined(_WIN32) || defined(__linux__) || defined(__ANDROID__)) so as
to match all the BSDs, and do the stat() before trying to fopen() the file.
Trying that in https://github.com/OSGeo/gdal/pull/4411
This will be post 3.3.2 material as it is not a new issue.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
