I wonder if you're suffering from NFS attribute caching?

My guess is that it could be reading the local stale cache and has just not seen the update yet. If you sleep for more than the attribute cache timeout (set in the NFS mount) it should correct itself. You could try a loop that sleeps for one second and then tests the file and see if it ever recognises the change.

Also, have you closed that file that you're writing to? I don't remember if this will flush the cache or not & I don't have a NFS server set up it test it on.

Have you checked that the nfs mount options are the same on both machines & that the defaults didn't change between versions?

You can set noac on the nfs mount but it does slow things down. Sadly, NFS is showing it's age and doesn't make a very good cluster file system.

Aaaaaaaaaand, it is a problem with the file not being closed. Something might have changed somewhere in Perl or SuSE in between these two version (of each).

Thank you very much for helping me out here! I'm short of 'vote' but I will come back later!

Didn't think for a second about NFS actually. Lets see...

My NFS has:

acregmin=3,acregmax=60,acdirmin=30,acdirmax=60

which are default values apparently. Therefore, I set a sleep to '3' and it didn't work "Failed". It is also much longer than the system() statement which works.

Now, I've looked at how I am writing my file: open, print and then... nothing. I added a close statement and it works like a charm. Let me double check on that though, I might have forgotten a switch somewhere that could affect that. I'll report back soon!

I would increase the verbosity of the error message. eg:

That way you can see that you are testing the right file and you will also see the error condition, if one exists.

It may also be that on your SuSE 11 box the file never gets created due to a permissions problem or somesuch. Do you check that it is opened correctly for writing and that the subsequent writes to it succeed?

So this is the code I have:

print "# File is located at: $myAbsPathToFile\n" if (-e $myAbsPathToFi
+le);

if (-s $myAbsPathToFile) {
    print "Good to go\n";
} else {
    print "# File $myAbsPathToFile is empty or missing: $!. Cannot con
+tinue!\n";
    exit;
}
[download]

And its output:

# File is located at: /nfs/home/frogsausage/file
# File /nfs/home/frogsausage/file is empty or missing: No such file or
+ directory. Cannot continue!
[download]

Note how awkward it is: first test is saying "Can find it, it exists!", and the second says "Nope, no such file or directory". These lines are like that in the final code: no statements in between and it isn't part of a loop or anything like that.

Edit: @hdb Indeed! I corrected typo after edit. I converted full path to variable again hence why. Thanks for the head up. Output is still the same after the typo edit.

There is a $ missing in

if (-s "myAbsPathToFile") {
[download]

Thanks for the tip. Didn't thought of printing the error message.

The error message returned on the SuSE 11/Perl 5.14.1 is "No such file or directory". At least it gives me why now. The sad thing is, if I stat the path of the file with 'ls' it gives me from your syntax (same terminal, without modifying anything) it says it can find it (correct rights, correct user and non-empty file).

File is created in my home and my home is on nfs.

Could the problem be due to use of auto mount of a NFS directory (given auto mount is actually being used)? For whatever reason, perhaps use of ls is more forceful than size or emptiness test. Then again both -- ls & -X -- get the information via stat call, no? Seems like something might have changed in perl + Suse combination.

Does calling stat() explicitly on file path (and not running system ls) before -[sz] make a difference?

Thanks for thinking of the NFS too. It seems something changed either in Perl 5.14.1 or in SuSE 11 with either the 'print' statement, the way test works on a filehandle, how the system deals with an open file...

Thanks for your input :) I'm short of 'vote' but I will come back later!

Just guessing: did you check that file permissions are the same on both machines?

Hi hdb, Actually, it is exactly the same file since it is located on a nfs directory. In the full script, I am now printing the value if a -e test returns true before going to the test that breaks and the path is exactly the same (which is expected).

...and the accounts on both machines have identical permissions and the NFS mounts are made in identical fashion i.e. with identical options, on the same mount point - each of which has identical permissions down to the mount point ?
A user level that continues to overstate my experience :-))

You won't believe it but...

print "# Command file is located at: $myAbsPathToFile\n" if (-e $myAbs
+PathToFile);

# system("ls -l $myAbsPathToFile");

if (-s $cmd_path) {# $myAbsPathToFile) {
  print "Good to go";
} else {
  print "Failed: $!";
}
[download]

gives "Failed: No such file or directory"

print "# Command file is located at: $myAbsPathToFile\n" if (-e $myAbs
+PathToFile);

system("ls -l $myAbsPathToFile");

if (-s $cmd_path) {# $myAbsPathToFile) {
  print "Good to go";
} else {
  print "Failed: $!";
}
[download]

gives "Good to go"

Same file, same code, same everything except that extra statement in between. An empty system(""); call does the same (works). Is a hidden/builtin Perl variable messing up with it or something? Ideas?!

Sorry for the double post, I just posted in the wrong hierarchy :(

Also, the shell does its own interpolation ( see system, sh ), and instead try

system 'ls', '-l', $myAbsPathToFile;
[download]

I just tried it and it works the same (as assumed) as my former system() call. The test result is "Good to go".

Ideas?!

its right about halloween

well, the extra system is commented out, but I imagine if a sleep(1) accomplishes the same thing, you have your answer (delay)

Sleep gives me the error again.

Halloween you said? No wonder why my comment to the empty system() statement is # trick or treat... fix for etc.

Let me try your syntax for system. Since system is taking an array as argument, I'm providing an array of '1' with "ls -l ...".

$! is only going to be meaningful if -s returned undef, not if it returned 0.