새 파일에 대해 ios fileExistsAtPath가 실패합니다.

파일을 작성한 다음 NSURLIsExcludedFromBackupKey 특성을 파일에 추가합니다. 이렇게하려면 내 HPSFileHelper 클래스에서 다음 두 가지 방법이 있습니다새 파일에 대해 ios fileExistsAtPath가 실패합니다.

+(void)writeDataToFileWithData:(NSData*)data andFilename:(NSString*)fileName 
{ 
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); 

    NSString *documentsDirectory = [paths objectAtIndex:0]; 

    NSString *filePath = [documentsDirectory stringByAppendingPathComponent:fileName]; 

    [data writeToFile:filePath atomically:YES]; 

    NSURL* fileURL = [NSURL fileURLWithPath:filePath]; 

    [HPSFileHelper addSkipBackupAttributeToItemAtURL:fileURL]; // Prevent this file from being backed up. 
} 

+(BOOL)addSkipBackupAttributeToItemAtURL:(NSURL *)URL 
{ 
    assert([[NSFileManager defaultManager] fileExistsAtPath: [URL path]]); 

    NSError *error = nil; 
    BOOL success = [URL setResourceValue: [NSNumber numberWithBool: YES] 
            forKey: NSURLIsExcludedFromBackupKey error: &error]; 
    if(!success){ 
     NSLog(@"Error excluding %@ from backup %@", [URL lastPathComponent], error); 
    } 
    return success; 

}

문제는 어설 ... fileExistsAtPath 가끔 실패한다는 것입니다. 아마도 이것은 어설 션이 실행될 때 파일이 완전히 작성 및 잠금 해제되지 않았기 때문일 수 있습니다. (대용량 파일 용)

이 문제를 해결하려면 어떻게해야합니까?

출처

2012-10-10 whatdoesitallmean

음 써트 fileExists 그래서 아마도 파일이 존재하지 않음을 확인하기 위해 설정되고 난 있지만, 때문에 완전히 작성되지 않은 될 수 있습니다 (실패 확실하지 않다). assert는 디버깅을 목적으로하기 때문에, 정말로주의해야 할 것은'addSkipBackupAttributeToItemAtURL :'이 생성되기 전에 그 경로에서 호출되는 이유입니다. 또한 설정중인 경로가 유효한지 확인하십시오. – mkral

writeToFile이 동기이고 파일이 메소드가 반환 할 때까지 작성되었음을 알 수 있습니다.

이 문제는 슬래시 문자 '/'가 포함 된 자동 생성 파일 이름이 발생하여 발생했습니다. 이것은 파일 생성에 실패했음을 의미합니다.나는 지금 writeToFile을 변경, 원자에 :

BOOL bWorked = [data writeToFile:filePath options:NSDataWritingAtomic error:&errorPtr]; 

if (!bWorked) 
{ 
    NSLog(@"writeDataToFileWithData failed for %@ %@", filePath,errorPtr); 
}

출처

2012-10-11 08:02:33 whatdoesitallmean

atomically: 매개 변수를 메서드로 사용하는 경우 가장 쉬운 방법은 NO입니다. 파일 작성

는

원자은 시스템이 임시 파일에서 파일의 콘텐츠를 쓰는 것을 의미하며,이 모든 것을 작성되면, 최종 경로에 파일을 이동합니다. 은 직접 파일을 작성 시스템을 만들 것입니다이 매개 변수에 대해 NO를 사용

(이것은 예를 들어 파일을 작성하는 동안 고장이 발생할 경우 최종 경로가 완료되지 않은 파일 내용을 포함하지 않음을 확인하기 위해 설계되었습니다) 최종 목적지/경로 (임시 파일을 사용한 다음 이동). 그래서

내 생각 엔있는 시간에 의해, atomically:YES를 사용하여 임시 파일을 사용할 때 시스템이 임시 파일을 작성 완료 할 수 없습니다 (따라서도에 이동을 시작하지 않았다 addSkipBackupAttributeToItemAtURL:를 부르는 최종 경로/목적지)를 표시하고 어설 션이 실패한 이유를 설명합니다.

atomically:NO을 사용하는 반면에 addSkipBackupAttributeToItemAtURL:을 호출하면 시스템에서 이미 최종 경로에 쓰기가 시작되었으므로 어설 션이 실패하지 않아야합니다.

출처

2012-10-10 22:49:02 AliSoftware

writeToFile:atomically:의 문서에 따르면

원자 적 YES, 데이터는 백업 파일에 기록되는 경우

하고 오류가 그때 가정 일어나지-백업 파일로 변경되고 path로 지정된 이름. 그렇지 않으면 데이터가 경로에 직접 기록됩니다. 당신이 [data writeToFile:filePath atomically:YES];를 호출 할 때 임시 파일이 작성되고 완료되지만 이름 바꾸기 아직이 경우 [[NSFileManager defaultManager] fileExistsAtPath: [URL path]]에 NO 반환 발생하지 않은 경우

그냥 가설 있지만, 전화는 반환 할 수 있습니다.

내 직감은 [data writeToFile:filePath atomically:NO]으로 전화를 전환하면이 버그가 사라질 것이라는 점입니다.

출처

2012-10-10 22:52:42

새 파일에 대해 ios fileExistsAtPath가 실패합니다.

답변

관련 문제