CoreXLSX
CoreXLSX copied to clipboard
XLSX File is not Read from documentPicker
Version 0.14.1
Description of the bug using documentPicker I tried opening an xlsx file however it does not open and it crashes to excel file is corrupted, I tried the solution from #160 but it did not work, I also tried to copy the file first to the bundle but it still does the same, also I tried to use fileExists originally with the url and filepath variable but still the same result Steps to reproduce
func documentPicker(_ controller: UIDocumentPickerViewController, didPickDocumentsAt urls: [URL]) {
let url = urls[0]
let filepath = url.path
let filemanager: FileManager = FileManager.default
let paths = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true)
let docDir = paths.first! as NSString
let excelfile = docDir.appendingPathComponent("temp.xlsx")
let fExcelFile = URL(fileURLWithPath: excelfile)
//try to save to internal memory
if filemanager.fileExists(atPath: excelfile) {
try! filemanager.removeItem(at: URL(fileURLWithPath: excelfile))
}
try! filemanager.copyItem(at: urls.first!, to: URL(fileURLWithPath: excelfile))
if filemanager.fileExists(atPath: excelfile) {
print("file is here\(excelfile) \(filemanager.isReadableFile(atPath: excelfile))")
//print(filemanager.pe)
}
guard fExcelFile.startAccessingSecurityScopedResource() else {
print("failed accessing security scope")
return
}
defer { fExcelFile.stopAccessingSecurityScopedResource() }
guard let file = XLSXFile(filepath: excelfile) else {
fatalError("excel file is corrupted")
return;
}
do {
for wbk in try file.parseWorkbooks() {
do {
for(name, path) in try file.parseWorksheetPathsAndNames(workbook: wbk) {
if let worksheetname = name {
print("This worksheet has a name \(worksheetname)")
}
let worksheet = try file.parseWorksheet(at: path)
for row in worksheet.data?.rows ?? [] {
for c in row.cells {
print(c)
}
}
}
}
catch {
}
}
}
catch {
}
}
}
Expected behavior code should read the xlsx file
Could you also share more details about this behavior? What do you mean by "file is not read"? Is an error thrown in the code that you're catching? Does it trigger any of the fatalError
or print
conditions? Have you stepped through the code with the debugger to pinpoint the exact line at fault?
Could you also share more details about this behavior? What do you mean by "file is not read"? Is an error thrown in the code that you're catching? Does it trigger any of the
fatalError
or
it triggers fatalError before I added startAccessingSecurityScopedResource fatalError("excel file is corrupted") when I added it as the solution from #160 it triggers the print statement print("failed accessing security scope")
In your code from the description, you're assigning a path URL passed by the document picker as let filepath = url.path
and never using it again, then you're trying to read from a new directory looked up by NSSearchPathForDirectoriesInDomains
. I'm not sure I understand how a document picker is relevant here if you're not reading anything from a path provided by it.
Originally this is what I did
let url = urls[0]
let filePath = url.path
guard url.startAccessingSecurityScopedResource() else {
print("failed accessing security scope")
return
}
defer { url.stopAccessingSecurityScopedResource() }
guard let file = XLSXFile(filepath: filePath) else {
fatalError("XLSX file at \(filePath) is corrupted or does not exist")
}
However it did not work so the next thing I tried was copy it to NSSearchPathForDirectoriesInDomains
The aim of the code is to pick an excel file from the document picker and read it but I had no luck in getting it to work
And in this original code, which exact line was bailing out, url.startAccessingSecurityScopedResource()
or XLSXFile(filepath: filePath)
?
url.startAccessingSecurityScopedResource()
Have you tried following this SO page? https://stackoverflow.com/questions/41144992/startaccessingsecurityscopedresource-return-always-false
According to it, startAccessingSecurityScopedResource
may return false
when the file is not secured, but it may still be readable.
Hi @tburnt, is this issue still reproducible for you?