1. Welcome to the new MacRumors forums. See our announcement and read our FAQ

Can NSFileManager open remote files?

Discussion in 'iPhone/iPad Programming' started by gameplayerxp, Jan 27, 2011.

  1. macrumors newbie

    gameplayerxp

    #1
    Hi,

    I have couple text files stored on a website and can be accessed via http protocol. Can NSFileManager query and open these files? I tried to construct a URL like this:

    Code:
    NSFileManager *fileManager = [NSFileManager defaultManager];
    NSURL *onlineURL = [NSURL URLWithString: @"http://www.myweb.com/temp"];
    NSError *error = nil;
    NSArray *onlineFiles = [fileManager contentsOfDirectoryAtURL:onlineURL includingPropertiesForKeys:[NSArray array] options:0 error:&error];
    
    But seemed that NSFileManager does not work.

    Any hints?

    Thanks.

    -Ray
     
  2. Moderator

    dejo

    Staff Member

    #2
    Does not work how? Please be specific. Are you getting compile-time warnings or errors? What about at run-time? It is crashing? If so, have you checked the crash logs? What debugging have you already done? Etc.
     
  3. macrumors newbie

    gameplayerxp

    #3
    The error happens at runt time. "contentsOfDirectoryAtURL" returns nil and error is "The operation couldn’t be completed. (Cocoa error 260.)". I'm running it in the simulator and the internet connection is available.

    Btw, is there any way to copy files to simulator? Thanks.
     
  4. Moderator

    dejo

    Staff Member

    #4
    Sounds like a server-side issue to me. Are you sure that your web server allows you to query a directory remotely? Just kinda guessing here, though. :)

    P.S. Are the files you're accessing static in name? If so, why not access them directly?
     
  5. macrumors 68030

    PhoneyDeveloper

    #5
    NSFileManager only works with file URLs.

    The iPhone Sim folder hierarchy is inside ~/Library/Application Support/iPhone Simulator. You can manipulate the files in there from the Finder (add, remove, delete, etc.) You can of course print out a full path to a file in your app's sandbox to see exactly where it is on your Mac.
     
  6. Moderator

    dejo

    Staff Member

    #6
    Hmm, why would contentsOfDirectoryAtURL:includingPropertiesForKeys:eek:ptions:error: be available then?
     
  7. macrumors 68030

    PhoneyDeveloper

    #7
    @dejo, I don't really understand what you're asking. For some reason Apple likes referencing file system files as URLs and it's added a bunch of new File System APIs over the past couple years that prefer URLs. But the only URLs that work are file system URLs (file:///path/to/my/file).

    The API you mention is one of these new URL APIs.

    If I'm wrong you can easily prove it by loading up a remote file. But I don't think it will work.
     
  8. Moderator

    dejo

    Staff Member

    #8
    Ah, so you're saying you can only use that API to access local files and not remote ones. Wow, that's quite the abuse of the U in URL! ;)
     
  9. macrumors newbie

    gameplayerxp

    #9
    Then that's what I guess. Thanks
     
  10. Moderator emeritus

    kainjow

    #10
    See this post :)
     
  11. macrumors 68030

    PhoneyDeveloper

    #11
    OK, that post and the NSURL docs do clarify things somewhat. As of MacOS X 10.6 and iOS 4.0 there have been some additions to NSURL to make it work better with files.

    However, quite a number of these new APIs are available on iOS 4.0 and later but not implemented. File reference URLs and bookmarks are unimplemented on iOS. They probably wouldn't be of much use anyway since users don't have direct access to the file system.

    File properties moves some functionality from NSFileManager directly into NSURL. That's a kind of distinction without a difference.

    The mentioned speed improvements might be useful if true. I don't see any real description of this or even a mention of this in the docs.

    I guess we can look forward to a deprecation of NSFileManager methods and NSString methods that deal with files soon. Oh joy.
     

Share This Page