How do I check if a file is locked?

[mishi_math]

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

 

[Harald Hein]

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.

 

[Chris Berg]

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

 

[Harald Hein]

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

**** you. Is that better?

 

[Roedy Green]

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]

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

 

[nils]

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.

 

[Bent C Dalager]

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

 

[Roedy Green]

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.

 

[Roedy Green]

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.

 

[Chris Berg]

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]

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