Skip to content
This repository has been archived by the owner on Jun 13, 2018. It is now read-only.

Directory iteration multiple issues. #73

Open
evoskuil opened this issue Mar 3, 2015 · 2 comments
Open

Directory iteration multiple issues. #73

evoskuil opened this issue Mar 3, 2015 · 2 comments

Comments

@evoskuil
Copy link
Member

evoskuil commented Mar 3, 2015

I'm encountering multiple problems attempting to use the latest build of GSL on Windows to enumerate files and/or directories.

Using the documentation as an example:

dir = directory.open(".", error_text) ?

if defined(dir)
  for dir.file as f
      echo "file:$(f.name) has size: $(f.size)"
  endfor
else
    abort "Error: " + error_text
endif

The run fails because f.name (and f.size) is undefined. But further trials also shows:

  • Based on the size of the enumerations, it's clear that all files and directories are enumerated (despite the dir.file qualification). This gives the same length enumeration as dir. even when there is a mix of files and directories in the opened directory.
  • When dir.directory is qualified, no directories (or files) are ever enumerated, the enumeration is always empty.
  • The enumerated objects (file and path) do define a path attribute, but it is always empty.
  • No documented attributes other than path are defined on returned files or directories.

This last item is not technically a break, but would make portable code hard, because presumably this is a behavior specific to Windows. But note that other path references in GSL on Windows don't require forward slashing:

  • The value of dir.path is correct in the case where the opened directory ends with "" but not when it ends with "/" (or when it is not terminated).
../libbitcoin/include  => x:\xxxxx\libbitcoin/
../libbitcoin/include/ => x:\xxxxx\libbitcoin/
../libbitcoin/include\ => x:\xxxxx\libbitcoin\include/

I'm really stuck at this point. I looked through the GSL source, but it's going to be a slog for me. Any help would be much appreciated!

@evoskuil
Copy link
Member Author

evoskuil commented Mar 4, 2015

I've located and resolved the last bullet item, just a case of hardwired "/" in some cases, where the code normalizes to the platform in other cases.

@evoskuil
Copy link
Member Author

evoskuil commented Mar 4, 2015

The other items are a consequence of UNICODE being defined. This implies that some code is issuing a UNICODE definition or API call.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant