bugGNU Octave - Bugs: bug #60875, Save function doesn't warn when...

 
 

bug #60875: Save function doesn't warn when disk is full

Submitted by:  Dennis <dizze>
Submitted on:  Sat 03 Jul 2021 10:06:31 AM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  6 Item Group:  Missed Error or Warning
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 16 Jul 2021 10:28:37 PM UTC, comment #4: 

I change the Priority on this by +1 because I feel it is a bad idea not to give an indication when save has failed.  What if this was data from an experiment that took 10 years to complete?  Or data from a space probe that will never be available again?

Rik <rik5>
Project Administrator
Sat 03 Jul 2021 06:09:15 PM UTC, comment #3: 

It's not like this is particularly difficult to solve, but it is tedious.  Saving data in Octave passes through a hierarchy of functions and finding the right spot to make the change is probably the critical strategic question.

It looks to me like one intervention needs to be made in

  load_save_system::save (const octave_value_list& args, int nargout)

in load-save.cc:1399.  This is where a filestream is opened, and after data is written via subroutines, where the filestream is closed.  An unwind_action object probably needs to be used to close the filestream if a subroutine throws an error ().

The second bit is harder.  Where in the tree of functions should the filestream (variable name "os") be checked for goodness?

Rik <rik5>
Project Administrator
Sat 03 Jul 2021 05:09:43 PM UTC, comment #2: 

Confirmed.

For testing, I used a file on /tmp which I mounted as a partition through a loopback device.  Most of these commands require root privilege.

dd if=/dev/zeros of=/tmp/filepartition bs=1M count=10
mkdir /mnt/tmp_filepartition
losetup /dev/loop0 /tmp/filepartition
mount /dev/loop0 /mnt/tmp_filepartition
chmod -R 777 /mnt/tmp_filepartition

For a test file, I used

x = rand (1e3, 1e3);
save x.mat x

I tried to save directly to the partition, and as reported here that leads to a truncated file with no warning whatsoever.

I tried the `copyfile` and `movefile` commands and they get it right.  See session log below.

octave:6> copyfile ('x.mat', '/mnt/tmp_filepart/')
cp: error writing '/mnt/tmp_filepart/x.mat': No space left on device
error: copyfile: operation failed:
error: called from
    copyfile at line 161 column 7
octave:7> movefile ('x.mat', '/mnt/tmp_filepart/')
mv: error writing '/mnt/tmp_filepart/x.mat': No space left on device
error: movefile: operation failed:
error: called from
    movefile at line 177 column 7

Rik <rik5>
Project Administrator
Sat 03 Jul 2021 03:34:36 PM UTC, comment #1: 

Confirmed. I created a 10 MB partition on an usb stick using gparted and tried to run the following:

a = rand (2000);
save -7 toto.mat
clear a
load toto.mat

In a sufficiently large file system and with -7 option I get a 29MB file, while on a the 10MB partition the resulting file is 5.7MB. Trying to reload the file leads to the following errors depending on the original format:

## With -7 format
error: load: error uncompressing data element (buf error from zlib)
## With -binary format
error: load: trouble reading binary file 'toto.mat'
## With default text format
error: load: failed to load matrix constant

Pantxo Diribarne <pantxo>
Project Member
Sat 03 Jul 2021 10:06:31 AM UTC, original submission:  

When saving a variable on a disk of limited size, and the disk runs out of space during saving, no warning or error is given. Octave just returns to the command prompt as if the save was successful.

Steps to repeat:
create a 10MB virtual drive (e.g. with veracrypt)

% create dummy variable that is bigger than 10MB
A = rand(1000,1000); % approx 20MB
save test.mat A

Dennis <dizze>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by dizze (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-07-16 rik5 Priority5 - Normal => 6
    2021-07-03 rik5 StatusNone => Confirmed
        Release6.2.0 => dev
    2021-07-03 pantxo Item GroupNone => Missed Error or Warning
        Operating SystemMicrosoft Windows => Any

    Back to the top


    Powered by Savane 3.6