Professional Web Applications Themes

Trouble checking for busy files (repost) - Mac Programming

Hi, I have an app which from time to time polls the contents of a folder. The folder is typically populated through ftp (but it could be through a shared folder on the LAN), so I need to wait for files to be completely uploaded/copied before handling them. I thought I could do that using PBHOpenDenySync, but I get a -50 (paramErr) whenever I call this routine. Then I thought I could try to open the file in fsRdWrPerm, but this is always successfull, even when the file is indeed being created by the ftp app. Then I tried the ...

  1. #1

    Default Trouble checking for busy files (repost)

    Hi,

    I have an app which from time to time polls the contents of a folder.

    The folder is typically populated through ftp (but it could be through a
    shared folder on the LAN), so I need to wait for files to be completely
    uploaded/copied before handling them.

    I thought I could do that using PBHOpenDenySync, but I get a -50 (paramErr)
    whenever I call this routine.

    Then I thought I could try to open the file in fsRdWrPerm, but this is
    always successfull, even when the file is indeed being created by the ftp
    app.

    Then I tried the following:
    flags = O_WRONLY | O_NONBLOCK | O_APPEND | O_EXLOCK;
    fd = open(path,flags);
    And again, the file is opened successfully, although it is being downloaded
    by the ftp client.

    I'm sure the file is busy, because when I try to delete it from the finder
    or programmatically, I get an error.

    Anyone knows a reliable strategy through Carbon, Cocoa or Darwin to check
    for a busy file ?

    Eric

    Eric Guest

  2. #2

    Default Re: Trouble checking for busy files (repost)

    In article <BCB48A2A.1FC73%fr>,
    Eric VERGNAUD <fr> wrote:
     

    Well, those locks are only advisory, so it'd only work if every other
    program accessing the file also used the lock.
     

    Maybe a call to /usr/sbin/lsof, with its output piped to your process?
    A call to something like
    popen("/usr/sbin/lsof | grep myfile", "r")

    --
    Tom "Tom" Harrington
    Macaroni, Automated System Maintenance for Mac OS X.
    Version 2.0: Delocalize, Repair Permissions, lots more.
    See http://www.atomicbird.com/
    Tom Guest

  3. #3

    Default Re: Trouble checking for busy files (repost)

    dans l'article tph-4ECAB0.14402127042004localhost, Tom Harrington à
    no.spam.dammit.net a écrit le 27/04/04 22:40:
     
    >
    > Maybe a call to /usr/sbin/lsof, with its output piped to your process?
    > A call to something like
    > popen("/usr/sbin/lsof | grep myfile", "r")[/ref]

    That does it ! Thank you so much.

    Eric

    Eric Guest

  4. #4

    Default Re: Trouble checking for busy files (repost)

    In article <BCB54CF0.1FCFC%fr>,
    Eric VERGNAUD <fr> wrote:
     
    > >
    > > Maybe a call to /usr/sbin/lsof, with its output piped to your process?
    > > A call to something like
    > > popen("/usr/sbin/lsof | grep myfile", "r")[/ref]
    >
    > That does it ! Thank you so much.[/ref]

    That's a gross hack, and it doesn't really work so well because you can't even
    match on the full pathname -- how do you propose to guarantee that no other app
    will have an unrelated file open with the same name as yours?

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  5. #5

    Default Re: Trouble checking for busy files (repost)

    dans l'article mit.edu, Miro
    Jurisic à org a écrit le 28/04/04 12:16:
     
    >>
    >> That does it ! Thank you so much.[/ref]
    >
    > That's a gross hack, and it doesn't really work so well because you can't even
    > match on the full pathname -- how do you propose to guarantee that no other
    > app
    > will have an unrelated file open with the same name as yours?
    >
    > meeroh[/ref]

    Well I AM matching on the full path name:

    XText cmdstr;
    char buffer[1024];
    FILE* stream;
    size_t read = 0;

    cmdstr = "lsof ";
    cmdstr += fPath;
    cmdstr.ToMacCString(buffer,sizeof(buffer));
    stream = ::popen(buffer,"r");
    if(stream)
    {
    read = ::fread(buffer,1,sizeof(buffer),stream);
    ::pclose(stream);
    }
    return read>0;

    But if you know a better way, you're welcome.

    Eric

    Eric Guest

  6. #6

    Default Re: Trouble checking for busy files (repost)

    In article <BCB555C9.1FD1A%fr>,
    Eric VERGNAUD <fr> wrote:
     
    > >
    > > That's a gross hack, and it doesn't really work so well because you can't
    > > even match on the full pathname -- how do you propose to guarantee that no
    > > other app will have an unrelated file open with the same name as yours?[/ref]
    >
    > Well I AM matching on the full path name:
    >
    > XText cmdstr; char buffer[1024]; FILE* stream; size_t read = 0;
    >
    > cmdstr = "lsof "; cmdstr += fPath;
    > cmdstr.ToMacCString(buffer,sizeof(buffer)); stream = ::popen(buffer,"r");
    > if(stream) {
    > read = ::fread(buffer,1,sizeof(buffer),stream);
    > ::pclose(stream);
    > }
    > return read>0;
    >
    > But if you know a better way, you're welcome.[/ref]

    Your code is much better than what was originally proposed (the
    popen(lsof|grep)), but you will still lose when the file path contains
    characters such as spaces.

    Also, your code makes no effort to detect if the file is open for reading or
    writing; for example, if a backup utility opens it, you won't access it while
    it's being backed up. This may be a bug.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  7. #7

    Default Re: Trouble checking for busy files (repost)

    dans l'article mit.edu, Miro
    Jurisic à org a écrit le 28/04/04 13:37:
     

    Good point. I've added commas around the path to take care of spaces.
     

    For the usage I'm having, this is ok. If I need more details, I can yze
    the output.

    Thanks for your precious advice.

    Eric

    Eric Guest

  8. #8

    Default Re: Trouble checking for busy files (repost)

    In article <mit.edu>,
    Miro Jurisic <org> wrote:
     
    >
    > Your code is much better than what was originally proposed (the
    > popen(lsof|grep)), but you will still lose when the file path contains
    > characters such as spaces.[/ref]

    Just trying to point in a useful direction, I didn't mean that to be
    implemented literally as stated (which is why I said "something like"
    that).

    Incidentally, regarding your other comment about knowing who has the
    file open-- the output from lsof will indicate both process ID and
    command, so this is pretty simple to deal with if necessary.

    --
    Tom "Tom" Harrington
    Macaroni, Automated System Maintenance for Mac OS X.
    Version 2.0: Delocalize, Repair Permissions, lots more.
    See http://www.atomicbird.com/
    Tom Guest

  9. #9

    Default Re: Trouble checking for busy files (repost)

    In article <BCB555C9.1FD1A%fr>,
    Eric VERGNAUD <fr> wrote:
     
    Download the source for lsof, and extract what you need.

    See <http://www.opensource.apple.com/darwinsource/10.3/lsof-12/> or
    <http://www.opensource.apple.com/darwinsource/tarballs/other/lsof-12.tar.
    gz>

    Reinder
    Reinder Guest

  10. #10

    Default Re: Trouble checking for busy files (repost)

    In article <wxs.nl>,
    Reinder Verlinde <invalid> wrote:
     

    That won't necessarily work -- lsof has to be setgid to do its work, and you
    don't want his app to have to be setgid. It's possible that lsof doesn't need
    setgid for this part of its functionality, you'd have to check.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  11. #11

    Default Re: Trouble checking for busy files (repost)

    In article <BCB57F9D.1FD4E%fr>,
    Eric VERGNAUD <fr> wrote:
     
    >
    > Good point. I've added commas around the path to take care of spaces.[/ref]

    I don't understand what you mean by this. Maybe you mean you added quotes?

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  12. #12

    Default Re: Trouble checking for busy files (repost)

    dans l'article mit.edu, Miro
    Jurisic à org a écrit le 28/04/04 21:50:
     
    >>
    >> Good point. I've added commas around the path to take care of spaces.[/ref]
    >
    > I don't understand what you mean by this. Maybe you mean you added quotes?
    >
    > meeroh[/ref]

    Yes.

    Eric

    Eric Guest

  13. #13

    Default What does setgid mean ?

    dans l'article mit.edu, Miro
    Jurisic à org a écrit le 28/04/04 21:50:
     
    >
    > That won't necessarily work -- lsof has to be setgid to do its work, and you
    > don't want his app to have to be setgid. It's possible that lsof doesn't need
    > setgid for this part of its functionality, you'd have to check.
    >
    > meeroh[/ref]

    What does setgid mean ?

    Eric

    Eric Guest

  14. #14

    Default Re: What does setgid mean ?

    In article <BCB5EF46.1FDF4%fr>,
    Eric VERGNAUD <fr> wrote:
     

    It means you need to read up on UNIX programming, because this topic is too big
    for me to explain it all here, but I will summarize: when an executable has the
    setgid bit set (which requires admin privileges to set), then the effective id
    of the executable, when launched, is not that of the user who launched it, but
    of the group who owns the executable. Therefore, it's possible to give an
    executable special privileges by creating a group that has those privileges,
    setting the group of the executable to that group, and setting the setgid bit on
    the executable.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  15. #15

    Default Re: Trouble checking for busy files (repost)

    Eric VERGNAUD wrote:

     [/ref]
     


    Maybe turn the problem around:

    lsof full-path-to-file

    If you get output, it means 'lsof' found something.
    If no output, then no-one has the file open _at_that_moment_.

    Read the man page for 'lsof' and examine all the other options
    that you can use to get better detection. (open for write?)

    Good luck!



    Mike Guest

  16. #16

    Default Re: Trouble checking for busy files (repost)

    In article <mit.edu>,
    Miro Jurisic <org> writes 
    >>
    >> That does it ! Thank you so much.[/ref]
    >
    >That's a gross hack, and it doesn't really work so well because you can't even
    >match on the full pathname -- how do you propose to guarantee that no other app
    >will have an unrelated file open with the same name as yours?
    >
    >meeroh[/ref]

    Ok but what *is* the right way then? I would like to be able to open a
    file in such a way that if another app tries to delete it (or write it)
    while I have it open, the other app will get "permission denied" or
    something. As it does on *gasp* Windows !!!!!!

    Any ideas?
    Andy Robinson, Seventh String Software, www.seventhstring.demon.co.uk
    Andy Guest

  17. #17

    Default Re: What does setgid mean ?

    dans l'article mit.edu, Miro
    Jurisic à org a écrit le 29/04/04 3:27:
     
    >
    > It means you need to read up on UNIX programming, because this topic is too
    > big
    > for me to explain it all here, but I will summarize: when an executable has
    > the
    > setgid bit set (which requires admin privileges to set), then the effective id
    > of the executable, when launched, is not that of the user who launched it, but
    > of the group who owns the executable. Therefore, it's possible to give an
    > executable special privileges by creating a group that has those privileges,
    > setting the group of the executable to that group, and setting the setgid bit
    > on
    > the executable.
    >
    > meeroh[/ref]

    That's just enough for me.

    Thanks,

    Eric

    Eric Guest

  18. #18

    Default Re: Trouble checking for busy files (repost)

    dans l'article 40909012$0$28904$rcn.com, Mike Hall à
    com a écrit le 29/04/04 7:18:
     [/ref]

    >
    >
    > Maybe turn the problem around:
    >
    > lsof full-path-to-file
    >
    > If you get output, it means 'lsof' found something.
    > If no output, then no-one has the file open _at_that_moment_.
    >[/ref]

    Which is exactly what I posted yesterday.

    Thanks anyway.

    Eric

    Eric Guest

  19. #19

    Default Re: Trouble checking for busy files (repost)

    In article <com>,
    Andy Robinson <com> wrote:

     

    That's not how UNIX works - "deleting" a file means removing a reference
    to it from the parent directory, but if that file is currently openned,
    that is _all_ that happens (i.e., the directory is updated to no longer
    refer to that file, but the file still exists, you can still read/write
    to it, you just can "get to it" from anything new).

    Note that more than one directory (on the same volume) can contain a
    reference to the file (hard link, which is different from an alias), so
    it is possible to "delete" a file from one directory, and it will still
    be present in another directly.

    To prevent a file from being deleted basically requires preventing
    something from being able to modify the directory that it is contained
    in - that's how UNIX works.

    (There are various UNIX file flags and Mac OS flags that can be set to
    make it more "difficult" to delete the file (depending on the API used
    to delete the file), but these can just as easily be cleared).
    Glenn Guest

  20. #20

    Default Re: Trouble checking for busy files (repost)

    In article <com>,
    Andy Robinson <com> wrote:
     
    > >
    > >That's a gross hack, and it doesn't really work so well because you can't
    > >even match on the full pathname -- how do you propose to guarantee that no
    > >other app will have an unrelated file open with the same name as yours?[/ref]
    >
    > Ok but what *is* the right way then? I would like to be able to open a file
    > in such a way that if another app tries to delete it (or write it) while I
    > have it open, the other app will get "permission denied" or something. As it
    > does on *gasp* Windows !!!!!![/ref]

    AFAIK there is no right way. It s. Read
    <http://developer.apple.com/technotes/tn/tn2037.html>

    hth

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

Similar Threads

  1. Can't save Fireworks files on OSX - file busy?
    By John T in forum Macromedia Fireworks
    Replies: 5
    Last Post: December 10th, 06:04 PM
  2. Checking Files in and out
    By rculver0621 in forum Coldfusion Server Administration
    Replies: 5
    Last Post: September 25th, 05:28 PM
  3. Checking files before uploading
    By gbert in forum Macromedia ColdFusion
    Replies: 10
    Last Post: April 20th, 06:14 PM
  4. About checking executable files
    By mhk in forum UNIX Programming
    Replies: 5
    Last Post: November 4th, 05:16 PM
  5. REPOST - print <c:\program files\*.*>;
    By Edward Yang in forum PERL Beginners
    Replies: 3
    Last Post: September 6th, 01:42 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139