How do I check if a file is locked?

Discussion in 'Java' started by mishi_math, Aug 22, 2003.

  1. mishi_math

    mishi_math Guest

    I should preface this by saying that I am using the following code.

    *******************************************************************
    if ( true == tempFile.canWrite() ) {
    String daf = monitorDir+"\\"+theList[x];
    File dirAndFname = new File(daf);
    boolean didItUpload = ftu.uploadToServer( monitorDir, theList[x]);
    if ( true == didItUpload ) {
    System.out.println( "It worked");
    System.out.println( "Rename file, did it work?
    "+tempFile.renameTo(renameFile));
    }
    else {
    System.out.println("It failed");
    }
    }
    *******************************************************************

    What I have a problem with is that I was editing on of the files in
    the directory that I was monitoring files and the canWrite() method
    said that the file was able to be written to, even though I was in
    edit mode and hadn't saved it.
    Is there a way to check that is more comprehensive? This may be a moot
    point, but I am not sure on how this file that will be placed in the
    directory will be placed there. Unknown because it is a piece of
    hardware writing the file out, have sent a question to the builder of
    it, but no answer yet.
    Oh...and as a note, if I make the files read only all is good too.
    Thanks for any assistance.
    Mishi
     
    mishi_math, Aug 22, 2003
    #1
    1. Advertising

  2. mishi_math

    Harald Hein Guest

    "mishi_math" wrote:

    > Subject: How do I check if a file is locked?


    You don't, because between the moment you do the check and your try to
    do something with the file the lock could have been changed.

    You do whatever you want to do with the file and handle potential
    exceptions.

    The same holds for your canWrite() test. Those tests are just bullshit.

    And your if(true == something()) tests are looking ugly like hell.
     
    Harald Hein, Aug 23, 2003
    #2
    1. Advertising

  3. mishi_math

    Chris Berg Guest

    On 23 Aug 2003 04:17:40 GMT, Harald Hein <> wrote:

    >And your if(true == something()) tests are looking ugly like hell.


    Don't just tell people that their code 'are looking ugly as hell'!

    Tell him WHY you think it looks ugly! (I would like to know that, too.
    If it's just a matter og reversing the operands, my personal view is
    that it is completely up to the author. Think of this parallel
    example: if (getText().equals("ABC") ... compared to if
    ("ABC".equals(getText())... The latter is, in my opinion, much
    better, because it allows getText() to return null without throwing a
    NullPointerException.)

    And remember, beauty is a very relative term !!

    Chris
     
    Chris Berg, Aug 23, 2003
    #3
  4. mishi_math

    Harald Hein Guest

    "Chris Berg" wrote:

    > Don't just tell people that their code 'are looking ugly as hell'!


    **** you. Is that better?
     
    Harald Hein, Aug 23, 2003
    #4
  5. mishi_math

    Roedy Green Guest

    On Sat, 23 Aug 2003 11:42:45 +0200, Chris Berg
    <> wrote or quoted :

    >>And your if(true == something()) tests are looking ugly like hell.


    see http://mindprod.com/jgloss/newbie.html

    He means please write that without stuttering.

    something() is already a boolean.

    if ( something() )

    For those that defend the stuttering style, I offer the slippery slope
    argument, then it will lead to:

    if ( ( something == true ) == true )

    Where will it all end? In Sodom no doubt.


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Aug 23, 2003
    #5
  6. mishi_math

    mishi_math Guest

    Thank you all for your assistance. And just to explain the reason for
    if ( true == something() )
    It is faster in the long run to have the known value to the left of
    the comparison field. And I always use true/false in my if statements
    for readability later.
    Thanks again.
    Mishi


    Roedy Green <> wrote in message news:<>...
    > On Sat, 23 Aug 2003 11:42:45 +0200, Chris Berg
    > <> wrote or quoted :
    >
    > >>And your if(true == something()) tests are looking ugly like hell.

    >
    > see http://mindprod.com/jgloss/newbie.html
    >
    > He means please write that without stuttering.
    >
    > something() is already a boolean.
    >
    > if ( something() )
    >
    > For those that defend the stuttering style, I offer the slippery slope
    > argument, then it will lead to:
    >
    > if ( ( something == true ) == true )
    >
    > Where will it all end? In Sodom no doubt.
     
    mishi_math, Aug 25, 2003
    #6
  7. mishi_math

    Guest

    > And just to explain the reason for :
    > if ( true == something() )
    > It is faster in the long run to have the known
    > value to the left of the comparison field.


    That's not true, why would :
    if ( true == something() )
    be any faster than :
    if (something() == true)

    In either case, 'something()' must be executed.

    It's only faster if you have more than one comparises, like :

    if ( something() && somethingElse() )

    Now, 'somethingElse()' will only be executed if
    'something() == true', so in this case it will be
    faster to put the fastest executing comparison
    first.
     
    , Aug 25, 2003
    #7
  8. In article <>,
    <> wrote:
    >
    >if ( something() && somethingElse() )
    >
    >Now, 'somethingElse()' will only be executed if
    >'something() == true', so in this case it will be
    >faster to put the fastest executing comparison
    >first.


    On the other hand, it would be faster to put the one that is most
    commonly false first because then you would minimize the amount of
    times both have to be evaluated.

    In cases when this kind of optimization is important, it will always
    be necessary to thoroughly study the situation at hand before deciding
    on a course of action and measure performance often while working on
    it. There are no silver bullets :)

    Cheers
    Bent D
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
     
    Bent C Dalager, Aug 25, 2003
    #8
  9. mishi_math

    Roedy Green Guest

    On 25 Aug 2003 05:56:46 -0700, (mishi_math) wrote
    or quoted :

    >It is faster in the long run to have the known value to the left of
    >the comparison field. And I always use true/false in my if statements
    >for readability later.


    It is LESS readable to anyone but yourself.


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Aug 25, 2003
    #9
  10. mishi_math

    Roedy Green Guest

    On Mon, 25 Aug 2003 15:18:06 +0200, wrote or quoted
    :

    >Now, 'somethingElse()' will only be executed if
    >'something() == true', so in this case it will be
    >faster to put the fastest executing comparison
    >first.


    That is one consideration. The more common one is dependency. e.g.

    if ( a != null && a.length() > 0 )

    You don't even wan to evaluate a.length unless a != null.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Aug 25, 2003
    #10
  11. mishi_math

    Chris Berg Guest

    On Sat, 23 Aug 2003 11:42:45 +0200, Chris Berg
    <> wrote:

    >On 23 Aug 2003 04:17:40 GMT, Harald Hein <> wrote:
    >
    >>And your if(true == something()) tests are looking ugly like hell.

    >

    I must say, it slipped my attention that the comparison was between
    boolean values, so of course, I agree with Roedy, don't compare 'true'
    or 'false' with another boolean expression!. I reality, 'something()'
    would be some readable method call, such as 'moreData()'. Now it would
    look less readable to say (true == moreData())', or even '(moreData()
    == true)'.

    My original point, though, was not as much the item itself, but the
    bad habit of just turning down the guy without even bothering to tell
    him why his code "looks ugly as hell".

    Chris
     
    Chris Berg, Aug 25, 2003
    #11
  12. mishi_math

    mishi_math Guest

    Point taken from all. It just so happen to be the way I was taught by
    co-workers and what their preferences are, but I do tend to agree with
    most of what was written here. Thanks much. Michelle


    Chris Berg <> wrote in message news:<>...
    > On Sat, 23 Aug 2003 11:42:45 +0200, Chris Berg
    > <> wrote:
    >
    > >On 23 Aug 2003 04:17:40 GMT, Harald Hein <> wrote:
    > >
    > >>And your if(true == something()) tests are looking ugly like hell.

    > >

    > I must say, it slipped my attention that the comparison was between
    > boolean values, so of course, I agree with Roedy, don't compare 'true'
    > or 'false' with another boolean expression!. I reality, 'something()'
    > would be some readable method call, such as 'moreData()'. Now it would
    > look less readable to say (true == moreData())', or even '(moreData()
    > == true)'.
    >
    > My original point, though, was not as much the item itself, but the
    > bad habit of just turning down the guy without even bothering to tell
    > him why his code "looks ugly as hell".
    >
    > Chris
     
    mishi_math, Aug 26, 2003
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Kamoski
    Replies:
    1
    Views:
    2,466
  2. MrB
    Replies:
    1
    Views:
    2,219
  3. Keith
    Replies:
    0
    Views:
    550
    Keith
    Oct 1, 2003
  4. hkappleorange

    database file locked by aspx

    hkappleorange, Nov 6, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    1,751
  5. Lawrence D'Oliveiro

    Re: Check file is locked?

    Lawrence D'Oliveiro, Jul 8, 2009, in forum: Python
    Replies:
    14
    Views:
    2,575
    squadjot
    Dec 18, 2009
Loading...

Share This Page