Add error for attempt to upload directory #5750
Conversation
| @@ -215,6 +215,13 @@ - (FIRStorageUploadTask *)putFile:(NSURL *)fileURL | |||
| - (FIRStorageUploadTask *)putFile:(NSURL *)fileURL | |||
| metadata:(nullable FIRStorageMetadata *)metadata | |||
| completion:(nullable FIRStorageVoidMetadataError)completion { | |||
| if ([fileURL frs_hasDirectoryPath]) { | |||
There was a problem hiding this comment.
Should we check that it is a file versus not a directory? Like https://github.com/firebase/firebase-ios-sdk/pull/5742/files?
There was a problem hiding this comment.
I will play with this. Maybe instead of the check looking like this:
if fileUrl is a directory -> return error
We could instead have something like?:
if !(fileUrl is a file) -> return error
There was a problem hiding this comment.
Good point, I think the 2nd option is preferable because there may be other types of URLs that are not handled now, e.g. a symlink or not a file system URL.
FirebaseStorageSwift/Tests/Integration/StorageIntegration.swift
Outdated
Show resolved
Hide resolved
FirebaseStorageSwift/Tests/Integration/StorageIntegration.swift
Outdated
Show resolved
Hide resolved
FirebaseStorageSwift/Tests/Integration/StorageIntegration.swift
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Basically LGTM. Please delete the extra files (the *.jpg files) and add a Changelog entry here: https://github.com/firebase/firebase-ios-sdk/blob/master/FirebaseStorage/CHANGELOG.md
This will likely be released with version 3.6.2, but you can also create a new "Unreleased" section.
…m:firebase/firebase-ios-sdk into nc-storage-directory-upload-attempt-error
|
Looks like I broke some of the objc unit tests by making the change to check that the passed in |
|
Updating the tests SGTM since its improving the tests with a more accurate error message, right? |
Yup, I believe so. Up until now, it looks like errors related to an invalid |
|
On second thought, I'm not completely certain, if the error message is considered part of the API |
| if (![_fileURL checkResourceIsReachableAndReturnError:&fileReachabilityError] || | ||
| ![self fileURLisFile:_fileURL]) { |
There was a problem hiding this comment.
The checkResourceIsReachableAndReturnError returns true or false depending on if the _fileURL can be reached. This is why attempts to upload directories weren't being caught in the first place, because they are reachable. Instead of doing a check in putFile:, I figured I should move the fileURLisFile helper method to FIRStorageUploadTask.m and call it in this isContentToUploadValid method so we have a single check to verify that the file we are trying to upload is both a reachable resource and it is a file.
| userInfo[NSLocalizedDescriptionKey] = [NSString | ||
| stringWithFormat:@"File at URL: %@ is not reachable. " | ||
| @"Ensure file URL is not a directory, symbolic link, or invalid url.", | ||
| _fileURL.absoluteString]; |
There was a problem hiding this comment.
I added some extra context to the error since we are now explicitly checking if the url points to a file.
In issue #5720,
putFilewas used to upload a.numbersdocument. Since.numbersis actually a directory and not a file, the method resulted in an error. The error is a bit misleading as it appears to come from the URLSession upload task.In an attempt to provide a better error for such cases, I added a check that validates that the
fileURLpassed intoputFileis indeed a file and not a directory.Since this is just a draft PR, I figured I could? include two documents (
Home Improvement.numbersandstar_wars.pdf) that support some initial tests I wrote for the addition I made toFIRStorageReference.m. If we decide to move forward with this, I would definitely take those out before opening a real PRI appreciate any feedback!