VSI ReadDir: Inconsistent handling of '.' and '..' directories.

[tveastman]

On-disk filesystems tend to have . and .. in their directory listings, but this behaviour is inconsistent between different VSI drivers.

a local filesystem listing, dots present

   >>> gdal.ReadDir('/home/vagrant/a-local-directory')
   ['..', 'file.txt', '.']

inside a zip file: no dot files

   >>> gdal.ReadDir('/vsizip//home/vagrant/a-local-directory/a-zip-file.zip/')
   ['a-zip-file']
   >>> gdal.ReadDir('/vsizip//home/vagrant/a-local-directory/a-zip-file.zip/a-zip-file')
   ['a-subdir', 'file-one.txt']

an EMPTY s3 bucket has a single '.' for some reason:

   >>>gdal.ReadDir('/vsis3/an-irish-bucket/')
   ['.']

...but if the bucket has contents, the . disappears:
   >>> gdal.ReadDir('/vsis3/public-bucket-gdal-vsis3-tests/')
   ['alpha', 'alpha/', 'beta']

I think the presence or absence of . and .. should be consistent in all calls to ReadDir() no matter what the underlaying driver is, my personal opinion is that they be removed from listings.

[Even Rouault]

Would probably makes sense to remove . and .. . "." is useful for an empty directory as the return of ReadDir() is not empty then. The code, in particular in /vsicurl, /vsis3 etc, currently more or less treats NULL or len() == 0 the same, so a fix for that would require treating them differently

[tveastman]

In Python, at least, it makes sense for an empty directory to simply be [], but is an empty list less meaningful at the lower level API?

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.