NSFileManager and making sure you don't overwrite existing files 10.5

  • The NSFilManager.h file says that the -fileExistsAtPath: method is "of
    limited utility... encourages odd behaviour"

    If I want to make sure that I'm not overwriting a file that's already
    on disk then should I really try loading the file so I get an error if
    it's not there?

    This seems a little roundabout, are there better ways to check this?

    With creating a directory the new method with an error is fine, and it
    doesn't overwrite an existing directory, but there doesn't seem to be
    an allegory for file creation.

    Jonathan
  • On Jan 18, 2008, at 5:46 AM, Jonathan Dann wrote:

    > The NSFilManager.h file says that the -fileExistsAtPath: method is
    > "of limited utility... encourages odd behaviour"
    >
    > If I want to make sure that I'm not overwriting a file that's
    > already on disk then should I really try loading the file so I get
    > an error if it's not there?
    >
    > This seems a little roundabout, are there better ways to check this?

    The problem is that "make sure you aren't overwriting a file" can give
    false negatives on a multi-tasking OS (and thus the comment - "man
    access" for a similar but more ominous comment).

    Basically, between the time you do your test and the time you actually
    write the file, another process can create a file there, rendering
    your test moot.  And if this file is involved in some sort of security
    feature, even worse things can happen (thus the "security hole" comment)

    So your work around of "try to load the file to see if there is an
    error" will perform no better.

    A better solution to avoid overwriting a file is to save to a
    temporary file and then use moveItemAtPath:toPath:error: which will
    give you an error if a file already exists there.

    Glenn Andreas                      <gandreas...>
      <http://www.gandreas.com/> wicked fun!
    quadrium | prime : build, mutate, evolve, animate : the next
    generation of fractal art
  • Thanks glenn I appreciate the quick reply, I thought that the
    multitasking would be the reason.

    Will that be the same way the save panel will work when it notifies
    the user that a file will be overwritten?  Its already written the
    file to /tmp and then will be moving it?

    Should I use /tmp or create a folder for my app in ~/Library/
    Application Support?

    Jonathan Dann

    On 18 Jan 2008, at 14:50, glenn andreas <gandreas...> wrote:

    >
    > On Jan 18, 2008, at 5:46 AM, Jonathan Dann wrote:
    >
    >> The NSFilManager.h file says that the -fileExistsAtPath: method is
    >> "of limited utility... encourages odd behaviour"
    >>
    >> If I want to make sure that I'm not overwriting a file that's
    >> already on disk then should I really try loading the file so I get
    >> an error if it's not there?
    >>
    >> This seems a little roundabout, are there better ways to check this?
    >
    >
    > The problem is that "make sure you aren't overwriting a file" can
    > give false negatives on a multi-tasking OS (and thus the comment -
    > "man access" for a similar but more ominous comment).
    >
    > Basically, between the time you do your test and the time you
    > actually write the file, another process can create a file there,
    > rendering your test moot.  And if this file is involved in some sort
    > of security feature, even worse things can happen (thus the
    > "security hole" comment)
    >
    > So your work around of "try to load the file to see if there is an
    > error" will perform no better.
    >
    > A better solution to avoid overwriting a file is to save to a
    > temporary file and then use moveItemAtPath:toPath:error: which will
    > give you an error if a file already exists there.
    >
    >
    > Glenn Andreas                      <gandreas...>
    > <http://www.gandreas.com/> wicked fun!
    > quadrium | prime : build, mutate, evolve, animate : the next
    > generation of fractal art
    >
    >
    >
  • Le 18 janv. 08 à 16:00, Jonathan Dann a écrit :

    > Thanks glenn I appreciate the quick reply, I thought that the
    > multitasking would be the reason.
    >
    > Will that be the same way the save panel will work when it notifies
    > the user that a file will be overwritten?  Its already written the
    > file to /tmp and then will be moving it?
    >
    > Should I use /tmp or create a folder for my app in ~/Library/
    > Application Support?
    >
    > Jonathan Dann
    >
    > On 18 Jan 2008, at 14:50, glenn andreas <gandreas...> wrote:
    >

    Quote from  "http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Art
    icles/WhereToPutFiles.html

    "
    Mac OS X provides an established set of directories for storing
    temporary files. The primary directory (/tmp) is where most local
    files go, but you should never hardcode this path into your
    application. Using hardcoded paths limits the portability and
    longevity of your code. Instead, Carbon applications should use the
    FSFindFolder function (in the Core Services framework) to obtain a
    reference to the temporary directory; Cocoa applications should use
    the NSTemporaryDirectory function in Foundation Kit.

    In your case, you may want to create your file on the same volume to
    be able to really move it and not have to copy/delete it (the move
    operation will take care of this transparently but if you move big
    file, it  may have some performance impact).

    Else I don't think you can locate a temporary directory on a defined
    volume using Cocoa functions, but Carbon File Manager can do it (using
    FSFindFolder with the target volume reference as first parameter).
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today