[Octave-bug-tracker] [bug #51388] Current directory does not change immediatly with "cd" on some systems

[Markus Mützel]

Follow-up Comment #13, bug #51388 (project octave):

On Windows, programs called with "system" run synchronously. When I run the
following command, the Octave command line is blocked until I close notepad:

system ('C:\Windows\notepad.exe')


Interestingly, when I run the following command, the command line is still
blocked in Octave. In Matlab, notepad executes asynchronously:

system ('C:\Windows\notepad.exe &')


But that is probably just a compatibility issue.


I will try and summarize what we tested for bug #51203 (leaving out the dead
ends but still quite long. Sorry.):

Calling the test script attached to comment #2, sometimes unexpected files and
folders appeared in the current directory on some systems. These files and
folders turned out to be the unpacked content of an xlsx template file.
xlswrite uses the Octave function "unpack" to un-zip the template to a
temporary folder (called in io's "__OCT_spsh_open__.m"). It turns out that
"unpack" lets InfoZip "unzip" decompress to the current directory. Thus it has
to change directories before calling "unzip". Somehow, the following lines in
"unpack" did not work as expected ("dir" being a temporary directory passed
from io - interesting choice of variable name ;-) ):

  unwind_protect
    cd (dir);
    [status, output] = system (sprintf ([command " 2>&1"], file));
  unwind_protect_cleanup
    cd (origdir);
  end_unwind_protect


The files were unzipped to the cwd *before* the "cd (dir)" command.
Calling "unzip" directly (instead of "unpack") to unzip the template file to
the temporary folder (without cd'ing to it) did prevent that.

However, at that point the xlsx file was still missing sometimes. The cause
was: InfoZip "zip" is called from io's "__OCT_spsh_close__.m". It turns out
that it is necessary to change to the temporary folder to have the correct
relative directory structure inside the resulting zip file. The symptoms were
the same: Sometimes zip executed as if the cwd was still the directory before
cd'ing to the temporary folder. Thus, it could not find the files to
compress.
The following construct helped to prevent that:

      while ! strcmpi(xls.workbook, pwd)
        cd (xls.workbook);
            pause (0.05);
      endwhile


That is probably what Mike led to suspect that something might be wrong with
"cd". (I think that he may be right.)

The only thing that was still necessary to make xlswrite succeed even in 2000
loops of the test script on Andrey's affected system, was to let "zip"
compress to the current directory (the temporary directory) and move the file
to the destination directory afterwards. (No "pause" necessary there any
more.)

For what I can tell, it looks like "cd" returns before the directory has
actually changed on some systems ("cd" running async?).

According to Philip, all affected systems have SSDs. But not all systems with
SSDs are affected. I could not reproduce on the two systems I have access to
(both with SSDs).

I hope that helps analyzing the behavior.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51388>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/