macOS isReadableFileAtPath: question

[mdeh]

In one of the programs from Kochan, the method

isReadableFileAtPath: is invoked prior to the method copypath:

So, given file1

If the existence of file1 can be determined by the method, say, "fileExistsAtPath:", and copypath: simply copies a path, why is it important to know about the readablility/writeability of a file prior to the copy method?

thanks as always.

 

[lee1210]

The only thing like copypath: i see in NSFileManager is:

- (BOOL)copyPath:(NSString *)source toPath:(NSString *)destination handler:(id)handler

One needs to be able to read the file or directory at the source path before it can be copied, so I'd guess that's why isReadableFileAtPath: is used. In this case a path is not being copied, but the object found there. A path is generally just an NSString, so copying a path itself definitely doesn't require any special checks.

-Lee

 

[mdeh]

One needs to be able to read the file or directory at the source path before it can be copied, so I'd guess that's why isReadableFileAtPath: is used. In this case a path is not being copied, but the object found there. A path is generally just an NSString, so copying a path itself definitely doesn't require any special checks.

-Lee

Maybe it actually reads and writes the object at the path?

Thanks Lee

 

[lee1210]

I couldn't find a copypath: method, so if the book wasn't discussing the method i found, I can't speak to what it is actually doing.

-Lee

 

[mdeh]

I couldn't find a copypath: method, so if the book wasn't discussing the method i found, I can't speak to what it is actually doing.

-Lee

My error..sorry:

It should be

copyPath:toPath:handler:

 

[lee1210]

Right-o, so that's the method i found, which does indeed copy something in the filesystem, hence requiring the ability to read it. I think perhaps in previous threads, and maybe in the book, the idea of what they mean by "Path" has been misleading. Normally one would not discuss a path without actually desiring to take some action with the object (file, directory, link, etc.) there, or put an object there, etc. A path without the item found there is pretty uninteresting, and you're unlikely to generate a path just for kicks. It's probably best to just think of it as the way to get to something interesting. It is not the same as the thing there, but without the thing there the path is a pretty useless piece of information.

-Lee

 

[mdeh]

Right-o, so that's the method i found, which does indeed copy something in the filesystem, hence requiring the ability to read it. I think perhaps in previous threads, and maybe in the book, the idea of what they mean by "Path" has been misleading. Normally one would not discuss a path without actually desiring to take some action with the object (file, directory, link, etc.) there, or put an object there, etc. A path without the item found there is pretty uninteresting, and you're unlikely to generate a path just for kicks. It's probably best to just think of it as the way to get to something interesting. It is not the same as the thing there, but without the thing there the path is a pretty useless piece of information.

-Lee

Lee, first 2 things.

1) The return value for isReadableFileAtPath: says this.

Return Value
YES if the invoking object appears able to read the file specified in path, otherwise NO. If the file at path does not exist, this method returns NO.

And part of the discussion for

copyPath:toPath:handler:

says this.

The file specified in source must exist,........

So, certainly using *isReadableFileAtPath* fulfills the obligation of querying the existence of the source file. But, in that case, why not use that specific method ie *fileExistsAtPath* ?
Perhaps I am missing what *isReadable* really means. Does it mean, is readable as in "Ascii" readable? Or is this computerese for telling me that the system will be able to *read*/*interpret* data that it needs in the copying process. Just curious?

 

[lee1210]

My guess (and it is a guess) is that while copyPath:toPath:handler: doesn't say so explicitly, if you are unable to read the object at the source path, the method will fail. That would be why just existence isn't sufficient. If there is something at the source path that you cannot read, fileExistsAtPath: will return YES, but copyPath:toPath:handler: will still fail.

-Lee

 

[mdeh]

My guess (and it is a guess) is that while copyPath:toPath:handler: doesn't say so explicitly, if you are unable to read the object at the source path, the method will fail. That would be why just existence isn't sufficient. If there is something at the source path that you cannot read, fileExistsAtPath: will return YES, but copyPath:toPath:handler: will still fail.

-Lee

Thanks Lee...