Implement contentsOfDirectoryAtPath

[euantorano]

Implementing NSFileManager::contentsOfDirectoryAtPath() and NSFileManager::subpathsOfDirectoryAtPath().

Error messages aren't currently an exact match for the standard Foundation library, which throws:

Fatal error: Error raised at top level: Error Domain=NSCocoaErrorDomain Code=260 "The folder “notexist” doesn’t exist." UserInfo={NSFilePath=/Users/euan/Desktop/notexist, NSUserStringVariant=(
    Folder
), NSUnderlyingError=0x1007019f0 {Error Domain=NSOSStatusErrorDomain Code=-43 "fnfErr: File not found"}}: file /Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-700.1.101.15/src/swift/stdlib/public/core/ErrorType.swift, line 56
(lldb)

Whereas this commit throws:

fatal error: Error raised at top level: Error Domain=NSCocoaErrorDomain Code=260 "The file notexist couldn’t be opened because there is no such file." UserInfo={NSFilePath=/Users/euan/Desktop/notexist}: file /Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-700.1.101.15/src/swift/stdlib/public/core/ErrorType.swift, line 56

However, I lack the knowledge to know what I'm missing with the NSError.

Otherwise, the test cases pass and this should hopefully work.

[parkera]

Overall this looks pretty good, with the minor comment on ._, which is worth testing.

Can you rebase this on top of master and into a single commit?

[euantorano]

Not a problem, I'll do so tonight once I've tested the ._ issue.

[euantorano]

@parkera Rebased and squashed, hopefully that's all fixed! Your comments about the ._ seem to have been lost, but basically the docs here seem to be wrong. The comments state that This method also does not return URLs for the current directory (“.”), parent directory (“..”), or resource forks (files that begin with “._”) when in actual fact files starting with ._ are indeed returned. This PR copies that behaviour, but removes that comment.

[phausler]

I am not certain this is the correct usage here; destroy is usually reserved from the initialized from swift scope buffers.

[euantorano]

@phausler That may be true, but I wasn't sure. It doesn't cause any errors, but if it's not needed then I can remove it.

On 17 Dec 2015, at 17:30, Philippe Hausler [email protected] wrote:

In Foundation/NSFileManager.swift:

 public func subpathsOfDirectoryAtPath(path: String) throws -> [String] {

•    NSUnimplemented()
  

•    var contents : [String] = [String]()
  

•    let dir = opendir(path)
  

•    if dir == nil {
  

•        throw NSError(domain: NSCocoaErrorDomain, code: NSCocoaError.FileReadNoSuchFileError.rawValue, userInfo: [NSFilePathErrorKey: path])
  

•    }
  

•    defer {
  

•        closedir(dir)
  

•        dir.destroy()
  

  I am not certain this is the correct usage here; destroy is usually reserved from the initialized from swift scope buffers.

—
Reply to this email directly or view it on GitHub.

[phausler]

After looking into it - it seems to be almost a no-op in this case

TIL...
Interesting - did some digging around in the standard lib:
It claims

  /// Destroy the object the pointer points to.
  ///
  /// - Precondition: The memory is initialized.
  ///
  /// - Postcondition: The value has been destroyed and the memory must
  ///   be initialized before being used again.

and then promptly calls

Builtin.destroy(Memory.self, _rawValue)

Which in turn ends up dealing with witness tables and seems to be primarily for object based buffers. So it would probably only matter if this was happening on UnsafeMutablePointer of CF types which are translated to swift retain/released objects.

[euantorano]

Interesting. Sounds like I can just remove it then without any downsides. I'll update this PR now.

[euantorano]

Fixed the concerns regarding .destroy(). Any other possible blockers?

[phausler]

looks pretty reasonable overall to me; just need to run tests before merging

[phausler]

on ubuntu I get this error:

Foundation/NSFileManager.swift:280:38: error: binary operator '==' cannot be applied to operands of type 'Int32' and 'Int'
                        if entryType == DT_DIR {
                           ~~~~~~~~~ ^  ~~~~~~
Foundation/NSFileManager.swift:280:38: note: overloads for '==' exist with these partially matching parameter lists: (Int32, Int32), (Int, Int)
                        if entryType == DT_DIR {

[euantorano]

Great. In OS X DT_DIR is an Int32, but obviously it's an Int on Linux. I'll add a conditional.

[euantorano]

Fixed, hopefully. I haven't tested on Linux, I'm setting up a VM to do so now.

[phausler]

yep, seems to be good now.

[euantorano]

👍