bugGNU Octave - Bugs: bug #59003, movefile.m shows message about...

 
 

bug #59003: movefile.m shows message about permissions

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Mon 24 Aug 2020 10:35:28 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Need Info Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Open
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 01 Sep 2022 04:07:16 PM UTC, comment #8: 

Oh I interpreted the movefile.m thing wrong, didn't see the rest of the if clause.
But it is Octave's movefile function that emits the messages. I'll see if tomorrow or early next week I can investigate further.

Just for completeness, for both your questions I get:
C:\Programs\Octave\octave-8.0.0_20220831H\usr\bin\mv.exe

(OT: I keep track of / separate various dev builds using the build date in the install dir name; I sometimes have two or three installed simultaneously)

Philip Nienhuis <philipnienhuis>
Group Member
Thu 01 Sep 2022 07:56:32 AM UTC, comment #7: 

Hmm. It is using the MSYS2 `mv.exe` for me with Octave 7.2.0 on Windows.

What does the following command return for you?

file_in_path (getenv ("PATH"), "mv.exe")


For me, it's:

>> file_in_path (getenv ("PATH"), "mv.exe")
ans = C:\PROGRA~1\GNUOCT~1\OCTAVE~3.0\usr\bin\mv.exe


Additionally, could you please show the output for the following command?

>> system("where mv")
C:\Program Files\GNU Octave\Octave-7.2.0\usr\bin\mv.exe
ans = 0


Markus Mützel <mmuetzel>
Group administrator
Thu 01 Sep 2022 07:19:57 AM UTC, comment #6: 

OK I had some time to investigate a little.

Turns out 'movefile.m' seems to invoke the "DOS"/Windows command "move.exe", and that is the command that emits the complaints. See L.71-79 of movefile.m:

:
  if (ispc () && ! isunix ()
      && isempty (file_in_path (getenv ("PATH"), "mv.exe")))
    ## Windows.
    cmd = "cmd /C move";
    cmd_force_flag = "/Y";
  else
    cmd = "mv";
    cmd_force_flag = "-f";
  endif
:


If I try with the MSYS2 'mv.exe' command, no messages are emitted (but no guarantees it can preserve permissions either :-) ). But - it does move the file.

As to the popup in comment #4, that isn't quite limited to Octave, I've seen that before in several other occasions.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 26 Aug 2020 05:06:16 PM UTC, comment #5: 

BTW I got that pic doing RMB on the zip file, then checking "Security" tab.
And maybe it is a red herring - I just did the same on some random file one of my other Windows PC's and I got exactly the same (and I have no admin privs there).

Philip Nienhuis <philipnienhuis>
Group Member
Wed 26 Aug 2020 05:01:32 PM UTC, comment #4: 

Checking permissions, I get the attached picture, showing that permissions of the source file for movefile.m had issues in the first place.
That zip file has been created by Octave's zip function, invoked from <io package>/private/__OCT_spsh_close__.m at L.53.

As until now I've seen it only on that one box at work and not on other Windows PC's I suppose it is a local issue.
Maybe just leave this bug report open until I've investigated a bit more.
Perhaps related: for some reasons I have admin privileges on that box (but I fail to see how that could cause trouble).


Philip Nienhuis <philipnienhuis>
Group Member
Wed 26 Aug 2020 10:42:21 AM UTC, comment #3: 

I'm not sure if the implementation of "mv" for msys2 differs. But reading about "mv" in bash, it does the following iiuc:
1. Copy the file from source to destination.
2. Set the permissions on the destination to match the source.
3. Delete the file at the source.

Step 2 can fail if the destination file system doesn't allow setting the permissions (typically the case on network shares) or if the user doesn't have permission to change the file permissions (that actually exists afaict).
If I got this right, the file won't be moved if the second step fails. Tbh, I don't know what that exactly means. Maybe the file is still copied. But the original file isn't deleted?

Does the file disappear at its source after the failed move?

Markus Mützel <mmuetzel>
Group administrator
Mon 24 Aug 2020 03:37:34 PM UTC, comment #2: 

A lot of questions ...

Does not occur with 5.2.0. But that has an older io package version, maybe that matters here.
It also happens with a crossbuild from July 27 that has io-2.6.2 (not yet released but as package maintainer I've been using it for many months now).
The relevant code in the io package hasn't changed for > some years.
I don't know the mxe-octave hg id, I wiped & restarted a new build tree on Aug. 8. The issue happens with builds from the old and the new tree.

The file (a zip archive w. another file name extension) got moved from a temp dir to the actual location. Otherwise the next step in some test script couldn't find it but it could.

No, this is on a legacy Win7 enterprise box that our ICT dept. would love to get rid of. (It still gets extended support ...)

No, it is on NTFS drives.

I see that it doesn't occur on my other build box (a much slower laptop) with a crossbuild from Aug. 5.
So maybe it is HW-related.
I'm unsure how to investigate further. Most of all I'd be interested in why and how the file permissions would change in the first place, and if and how that might be influenced by Octave

Philip Nienhuis <philipnienhuis>
Group Member
Mon 24 Aug 2020 11:29:25 AM UTC, comment #1: 

Does the same error occur with Octave 5.2.0?
Which version/hg id of Octave? And probably more importantly: Which hg id of MXE Octave did you use?

Was the file actually moved after that error/message?

Did you recently upgrade the OS?

Are you moving the file between different file systems?

Markus Mützel <mmuetzel>
Group administrator
Mon 24 Aug 2020 10:35:28 AM UTC, original submission:  

The command movefile.m started emitting a message about file permissions:

:
[mvst, msg] = movefile (["." filesep fname ".zip"], filename, "f");
mv: preserving permissions for 'D:/tmp/io-test.ods': Not supported
:


While the message might be useful in selected cases I see no movefile.m command line switches allowing file permissions to be influenced during its operations.

I think this is a very recent change. I don't know if it changed in mingw (mxe-octave) or in Octave.

Philip Nienhuis <philipnienhuis>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-08-26 philipnienhuis Attached File- Added permissions-zip.png, #49710
    2020-08-24 mmuetzel StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code