Re: NSFileManager contentsEqualAtPath

FROM : Gerriet M. Denkmann
DATE : Tue Aug 15 18:40:28 2006

On 14 Aug 2006, at 23:57, Michele Balistreri wrote:

> It might have something to do with caching i think. Now that's just 
> a guess, i don't know how exactly the AFP (i suppose you use AFP

yes, this is correct.

> ) server/client are implemented but it may cache some data not get 
> the updates immediately. Try for example stopping/restarting file 
> sharing.

Again: correct. Unmounting + remounting fixes the problem.

But this is not a workaround.


> Again, i'm not sure this is the answer, but you should take a look 
> at that.
>
> Il giorno 14/ago/06, alle ore 22:57, Gerriet M. Denkmann ha scritto:
>

>> Computer A has mounted via Finder some home directory of computer B.
>>
>> A program does on A:
>>
>> NSFileManager *fileManager = [ NSFileManager defaultManager ] ;
>> NSString *localPath = @"/Users/userid/Desktop/Test1/a"; <-- on 
>> computer A
>> NSString *distantPath = @"/Volumes/userid/Desktop/Test1/b"; <-- on 
>> computer B
>> BOOL ok = [ fileManager copyPath: localPath  toPath: distantPath 
>> handler: nil ];
>> // ok
>>
>> Then the user deletes the last line (2 bytes + \n) of file b on 
>> computer B .
>>
>> Now the program does on A:
>> BOOL same = [ fileManager contentsEqualAtPath: distantPath 
>> andPath: localPath ];
>> // same <-- strange
>>
>> but the other way round:
>> BOOL sam2 = [ fileManager contentsEqualAtPath: localPath andPath: 
>> distantPath ];
>> // not same <-- strange
>>
>> the user does on computer A:
>> ls -l /Users/userid/Desktop/Test1/a --> 53 bytes
>> ls -l /Volumes/userid/Desktop/Test1/b --> 53 bytes <-- strange
>>
>> the user does on computer B:
>> ls -l /Users/userid/Desktop/Test1/b --> 50 bytes
>>
>> the user opens distantPath  on computer A in a hex editor and sees 
>> 50 bytes as expected, followed by 3 zero bytes.
>>
>> What is my program doing wrong that it gets such strange and 
>> unexpected results?
>> (both computers 10.4.7 ppc)
>>
>> Gerriet.