Re: wait_for_file ??

[John W. Eaton]

On  9-Sep-2010, Shai Ayal wrote:

| On Thu, Sep 9, 2010 at 3:15 PM, Ben Abbott <address@hidden> wrote:
| >
| > Why not always use ... fid = popen ("cat ...")?
| >
| >        fid = popen (pipeline, "w")
| >
| > where `pipeline' is a string containing a piped command line. Which could 
be just gs. For "print test.jpg" ...
| >
| >        pipeline = "cat | gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=jpeg 
-dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150 -dEPSCrop 
-sOutputFile=test.jpg"
| >
| > For fig ..
| >
| >        pipeline = "cat | pstoedit -f fig test.fig"
| >
| > For emf ...
| >
| >        pipeline = "cat | pstoedit -f fig | fig2dev -L emf test.emf"
| >
| > I'm not sure the "cat" is needed except in Shai's example, but you using 
this approach a pipeline of conversions can be implemented.
| 
| The cat is not needed. I just used it for the example.

If you can arrange for the entire sequence of print commands to be a
pipeline, then that should take care of any race conditions related to
file creation within the print command.

It occurred to me later that there could still be problems for things like

  print ("-depsc", "foo.eps");
  system ("lpr -P foo.eps");

since the print command relies on external programs.  But I don't know
for sure.  Is it possible that even though the print command is
waiting for the external commands to exit and flush their output to
files, that the file will not exist by the time the next command is
executed?

Was that the original problem, that a sequence of commands in Octave
like

  system ("gnuplot ...");  ## generate eps file
  system ("gs ...");       ## convert eps file to some other format

was failing because the output file from the first command was not
available when the second command was executed?  If so, do we still
not understand why that can happen?  Can it happen in a sequence of
shell commands run from bash (for example)?  If not, then what is
different there than in Octave?

What were the specifics of the case(s) that were failing?  What types
of systems, filesystems, etc.?  If it only occurred on network mounted
filesystems that have the async option set, then I guess I'm not
surprised by the failure.  From the exports man page on my system:

  EXPORTS(5)               Linux File Formats Manual              EXPORTS(5)

  NAME
         exports - NFS file systems being exported (for Kernel based NFS)

     General Options
         exportfs understands the following export options:

         ...

         async  This option allows the NFS server to violate the NFS
                protocol and reply to requests before any changes
                made by that request have been committed to stable
                storage (e.g. disc drive).

                Using this option usually improves performance, but at
                the cost that an unclean server restart (i.e. a crash)
                can cause data to be lost or corrupted.

If the problem also happened on local filesystems, or NFS filesystems
with the sync option set, then I'm not sure why it would happen, or
how to avoid the problem.

jwe