Issue with FileHandle(forReadingFrom:)

[fswarbrick]

Take the following program:

import Foundation
import Libc

func readAs(path: String) {
    print("Opening '\(path)' as file path.")
    if let f = FileHandle(forReadingAtPath: path) {
        process(file: f)
    }
    else {
        print("Open failed; errno: \(errno)")
    }
}

func readAs(url path: String) {
    print("Opening '\(path)' as file URL.")
    process(file: try! FileHandle(forReadingFrom: URL(fileURLWithPath: path)))
}

func process(file: FileHandle) {
    print("Successful open")
    let d = file.readDataToEndOfFile()
    print("Read \(d)")
    if let s = String(data: d, encoding: .utf8) {
        print(s)
    }
    file.closeFile()
}

func main() {
    let fileName = CommandLine.arguments[1]
    readAs(path: fileName)
    readAs(url: fileName)
}

main()    

This program works fine when the file specified as arg 1 exists, but when it does not exist the attempt to open it using try! FileHandle(forReadingFrom: URL(fileURLWithPath: path)) actually returns a FileHandle instead of throwing an error. But a FatalError occurs on the attempt to read the file using that FileHandle.

DVFJS:/u/dvfjs/src:>./files dummy.txt                                                                                               
Opening 'dummy.txt' as file path.                                                                                                   
Open failed; errno: 129                                                                                                             
Opening 'dummy.txt' as file URL.                                                                                                    
Successful open                                                                                                                     
Fatal error: Unable to read file: file Foundation/FileHandle.swift, line 42                                                         
CEE3201S The system detected an operation exception (System Completion Code=0C1).                                                   
         From entry point $Ss17_assertionFailure__4file4line5flagss5NeverOs12StaticStringV_SSAHSus6UInt32VtFTf4nxnnn_n at compile un
it offset +000000001060AE96 at entry offset +00000000000000FA at address 000000001060AE96.                                          
[1] + Done(132) ./files dummy.txt                                                                                                   
  50463486      FSUM7739 Illegal instruction    ./files                                                                             
DVFJS:/u/dvfjs/src:>swiftc --version                                                                                                
5655-SFT V4.2 - IBM Toolkit for Swift on z/OS version 4.2.1-dev (LLVM 2ab0e7e2b7, Clang bf22bdb497, Swift df4dbc99f7)               
Build Date: Nov 25 2018 11:18:42                                                                                                    
Target: s390x-ibm-zos                                                                                                               

[travatine]

The above code works as correctly on Swift on Linux ; and I too can reproduce the above error on Swift 4.2.1 of z/OS.

A workaround for the z/OS specific bug might be;

if( FileManager.default.fileExists(atPath: path) ) {
// read the file using URL ...
} else {
// file does not exist
}

[IgorTodorovskiIBM]

Thanks, we are able to reproduce the issue as well. We have a fix we're testing and will provide an updated build soon.

[fswarbrick]

The above code works as correctly on Swift on Linux ; and I too can reproduce the above error on Swift 4.2.1 of z/OS.

A workaround for the z/OS specific bug might be;

if( FileManager.default.fileExists(atPath: path) ) {
// read the file using URL ...
} else {
// file does not exist
}

Yeah, I made sure to validate it against Linux as well, as there is probably no point in reporting an upstream error as z/OS specific.

[fswarbrick]

Thanks, we are able to reproduce the issue as well. We have a fix we're testing and will provide an updated build soon.

Sounds good. I have no urgent need. Just something I noticed whilst "playing around".