bugGNU nano - Bugs: bug #58642, potential data loss when...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58642: potential data loss when overwriting existing files

Submitter:  Michalis Kokologiannakis <michalis>
Submitted:  Mon 22 Jun 2020 04:36:41 PM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Thu 30 Jul 2020 07:17:15 AM UTC, comment #28: 

(Thanks for the test case.)

The fix for this issue has been released in nano-5.0.

Benno Schulenberg <bens>
Group administrator
Sun 26 Jul 2020 02:31:18 PM UTC, comment #27: 

For completeness, here is a test case showing how data loss can occur under ext4 (assuming the old backup procedure with no fsync()s).

The idea is to have some synchronous I/O going on while saving a file (e.g., writing a lot of small files with fsync()), and crash during of after the save.

The script fires up a session, waits for some seconds, starts the I/O, and then crashes the machine once the user exits the editor. So one way to use it would be to edit the file (without changing the size), wait for the I/O to start, and save after pressing ^X. Otherwise, manually doing something similar to what the script does should suffice (even better if the machine crashes during saving).

(file #49549)

Michalis Kokologiannakis <michalis>
Thu 09 Jul 2020 03:03:23 PM UTC, comment #26: 

Thank you for your help.

I will open separate tickets for the cleanups, although probably early next week.

Michalis

Michalis Kokologiannakis <michalis>
Thu 09 Jul 2020 02:38:52 PM UTC, comment #25: 

V3 of your patch has been pushed to master, commit a84cdaaa, with a small message tweak.  Thank you for all the work!

(If you want to follow up with cleanup patches, the first one would be to move the backup code to a separte function -- just moving the entire piece of code, making only the changes necessary for it to become a separate function.  A further patch could then make small rearrangements and comment improvements and whatever else you think can be improved.  If there are multiple things to be improved, please do them in separate patches.  But better just take it one step at a time.  Please post those patches in a new issue, or better under Patches.)

Benno Schulenberg <bens>
Group administrator
Sat 04 Jul 2020 01:48:38 PM UTC, comment #24: 

Thank you.  Looks good.  The only improvement I would suggest is to add a "~" before the "XXXXXX", in both cases.  This makes the name more readable, and the "~" kind of indicates that it is backup file.  With that improvement, please send the patch to the devel list (with git send-email, or otherwise as an attachment).

Benno Schulenberg <bens>
Group administrator
Sat 04 Jul 2020 10:47:56 AM UTC, comment #23: 

Here's what I have now; this version should not overwrite existing backups when making temporaries.

Thank you,
Michalis

(file #49422)

Michalis Kokologiannakis <michalis>
Fri 03 Jul 2020 05:30:12 PM UTC, comment #22: 

Thanks for thinking this through.  Yes, when the user did not request any backups, nano should not overwrite any existing files -- as you said earlier: the user might want to retain certain tilded backups in their home directory (or anywhere else).

Thinking a bit about it, it's obvious: when not requested to make a backup, nano should make sure that the failsafe, temporary backup does not clash with any existing file.  So, yes, your suggested change to the if statement looks good.  (The label will then have to be renamed back to 'try_backup', otherwise it doesn't make sense for that case.)

Benno Schulenberg <bens>
Group administrator
Fri 03 Jul 2020 04:06:39 PM UTC, comment #21: 


> You say that you think that "nano should go on with the failsafe backup in case the first attempt fails (even if --backupdir is specified)".  But... that is what the current patches are doing, or is it not?


It is. What I meant was that, even though it introduces the complications I wanted to discuss, I still think it is a better approach.

> True, I've thought about it too: making a tilded backup in the home directory might overwrite an existing backup of a different file with the exact same name.  That is indeed a risk.  (But... how many people really keep files with a suffixed tilde in their home directory for safe keeping?  If anyone really wants to keep old stuff around, they make a special directory for it, I imagine, and store things there.)


I agree with you. But I do not know if this is a concern for others.

> The problem with using /tmp is that it is likely to be cleared on a reboot, so... if the user has specified -B, these "fallback" backups will not survive a reboot.  HOME does not have this problem.


Indeed, I should not have mentioned /tmp, it beats the purpose.

So, assuming that overwriting backups in HOME is indeed something we want to avoid, here is another attempt. In the patch, if something goes wrong during the backup, backup_error will create a temporary file at HOME using mkstemp(). Then, nano will retry, in a similar manner to the previous patches. 

I also noticed that, previously, backup_file was not reset to NULL if the first backup attempt failed, which might had created problems in the second attempt (if it were backup_fd < 0). So the patch also fixes that.

Finally, there is still one case that we might want fixed. If there was a backup for a file and then we edit the file without "-B", if we cannot create a new backup, the file will be left with no backup. Is this a concern too? (I guess if the write goes through it does not matter, but if it does not, it may be.) If it is, we could change the if-statement that creates backupname to something like:


if (!ISSET(MAKE_BACKUP))
    /* create a name using tmpnam() or mkstemp() + goto retry_backup */
else if (backupdir == NULL)
    ...
else
    ...


What do you think?

Thank you,
Michalis

(file #49420)

Michalis Kokologiannakis <michalis>
Thu 02 Jul 2020 12:28:16 PM UTC, comment #20: 

Hello Michalis,

You say that you think that "nano should go on with the failsafe backup in case the first attempt fails (even if --backupdir is specified)".  But... that is what the current patches are doing, or is it not?

When -B is not specified, I don't want nano to ask anything, becaue the failsafe backup is made only to make sure not to lose data -- the user didn't ask for it and probably never knows about it.

True, I've thought about it too: making a tilded backup in the home directory might overwrite an existing backup of a different file with the exact same name.  That is indeed a risk.  (But... how many people really keep files with a suffixed tilde in their home directory for safe keeping?  If anyone really wants to keep old stuff around, they make a special directory for it, I imagine, and store things there.)

But if we use /tmp instead, then we must make sure that the (failsafe or requested) backup gets a unique name, because there may already be a file with the same name plus tilde there (maybe even belonging to a different user, so it is impossible to overwrite it).

Hmmm...  Okay, we are not allowed to risk overwriting the user's data in HOME.  So we must use /tmp.  And in that case we must create a unique name, and it must be guaranteed to be writable.  So we must use mkstemp().

The problem with using /tmp is that it is likely to be cleared on a reboot, so... if the user has specified -B, these "fallback" backups will not survive a reboot.  HOME does not have this problem.

Benno Schulenberg <bens>
Group administrator
Thu 02 Jul 2020 10:02:59 AM UTC, comment #19: 

Hello, Benno,

(Posting a tentative v2 here before sending to nano-devel, since I have a question. Feel free to reply there if you think this is of general interest.)

I still think that nano should go on with the failsafe backup in case the first attempt fails (even if --backupdir is specified). But I have an extra concern.

Do you think it would be better if nano asked before doing so? Or maybe used /tmp instead of $HOME for the second attempt? I am wondering whether we somehow want to prevent nano from replacing a backup of a file that the user intentionally keeps at $HOME; the backup may be of a different file that simply has the same suffix as the one being edited.

Thank you,
Michalis

(file #49407)

Michalis Kokologiannakis <michalis>
Tue 30 Jun 2020 02:03:01 PM UTC, comment #18: 

Sure. I will take another look at the patch as well.

Michalis Kokologiannakis <michalis>
Tue 30 Jun 2020 01:52:45 PM UTC, comment #17: 

About the parentheses: yes, added locally.  Thanks.  I'm surprised I missed those.  :)

Refactorings and cleanups can be done later.  First I want to send the current patch to nano-devel.  Is that okay with you?  Maybe other people see problems we are overlooking, or maybe they have useful comments.

Benno Schulenberg <bens>
Group administrator
Tue 30 Jun 2020 10:52:54 AM UTC, comment #16: 

Seems good to me! For what it is worth, I do prefer the latter approach regarding write failures to a specified backupdir.

(Minor comment/nitpicking: wouldn't it be better if ISSET(MAKE_BACKUP) in backup_error was enclosed in parentheses, as in the rest of the code?)

Please let me know if I can help with further refactorings/cleanups.

Thank you,
Michalis

Michalis Kokologiannakis <michalis>
Tue 30 Jun 2020 09:28:35 AM UTC, comment #15: 

Concerning a write failure to a specified backupdir, I have reconsidered.  Such a write might fail if it is on a different device and that device is full, or if it is a remote device and the network is down.  In those cases nano should still ensure that no data loss can occur and should try and write the backup to the user's home directory.  So I've changed the attached patch accordingly.

Also, even after calling get_homedir(), 'homedir' might still be NULL, so the code needs to take that into account -- done in the attached patch.  And to answer one of your questions: yes, when a backup in the regular place fails, it's better that nano warns about this before trying again in $HOME -- added to the patch.

Patch is also rebased to current master.  What do you think?

(file #49396)

Benno Schulenberg <bens>
Group administrator
Mon 29 Jun 2020 06:11:42 PM UTC, comment #14: 

Attached is an edited version of your patch, to reduce the number of unnecessary changes (things can be optimized and comments can be adjusted later), and the two fixes folded in.  I've also added a check to prevent a second attempt when '--backupdir' was used: I think that a write failure to a specified backup dir is a user error that nano does not need to pardon.  What do you think?

(file #49394)

Benno Schulenberg <bens>
Group administrator
Mon 29 Jun 2020 03:05:42 PM UTC, comment #13: 

The fixup stops nano from crashing vocally, but now the "free(): invalid pointer" appears in both cases: with and without --ignore.  I think my Ubuntu does extra checking on free(), possibly detecting a double free?

This is what valgrind says:
==17694== Invalid write of size 1
==17694==    at 0x53166DF: vsprintf (iovsprintf.c:43)
==17694==    by 0x52FA093: sprintf (sprintf.c:32)
==17694==    by 0x40A6BD: write_file (files.c:1777)
==17694==    by 0x40B3B3: do_writeout (files.c:2313)
==17694==    by 0x40B809: do_savefile (files.c:2334)
==17694==    by 0x4135CD: process_a_keystroke (nano.c:1621)
==17694==    by 0x41475B: main (nano.c:2506)
==17694==  Address 0x592216e is 0 bytes after a block of size 14 alloc'd
==17694==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17694==    by 0x41FFBB: nmalloc (utils.c:295)
==17694==    by 0x40A696: write_file (files.c:1776)
[...]

Then I realized: you reserve one byte too few: you have "+ 2", one for "/", one "~", but the one for the terminating NUL byte is missing.

With that change, things are working well so far.

Benno Schulenberg <bens>
Group administrator
Mon 29 Jun 2020 01:05:21 PM UTC, comment #12: 

Thanks for spotting this. I had tried that exact test case before sending it out but it did not crash for me (although it does crash if I use --ignore).

I think the problem is that homedir might not be set under all circumstances; fix attached (applies on top of the previous patch).


(file #49385)

Michalis Kokologiannakis <michalis>
Mon 29 Jun 2020 12:41:23 PM UTC, comment #11: 

Thanks for working on this.  The latest patch looks okay, but... when I tried it without using any options, nano crashes when the target directory is unwritable.  For example:

sudo mkdir box
sudo touch box/foo
sudo chmod a+w box/foo
echo "text" >box/foo
src/nano --ignore box/foo

Type some more text, then type ^S.  Nano crashes.
(When not using --ignore, nano prints "free(): invalid pointer" after the message on the status bar and the terminal is locked up.)

Concerning your questions: let's first iron out the bugs in the current patch.  We can make refinements in later patches.

Benno Schulenberg <bens>
Group administrator
Mon 29 Jun 2020 11:47:12 AM UTC, comment #10: 

Sorry, I just noticed that I uploaded a version with minor errors. Try this one instead.

(file #49384)

Michalis Kokologiannakis <michalis>
Mon 29 Jun 2020 11:18:18 AM UTC, comment #9: 

Ok, so here is a summary of a revised version:

- First, we get the name of the backup. If this fails, we exit just as before (although that could change; see below).
- Then, we try renaming the file to create the backup. If this succeeds, write out can proceed.
- If renaming fails, we try copying. If copying succeeds, the write out can proceed.
- If copying fails, we try again, but this time at HOME. If this also fails, we notify the user, and only proceed if the user wishes so.

And some questions:

- Should nano give the user the option to continue if --backupdir is specified but too many backups have been created?

- Before retrying to copy the file, a partial backup that might have been created in the first try is deleted. In case a failsafe cannot be created either, should it be deleted as well? (By default nano would just leave a partial backup be.)

- There is one thing that's different compared to what was happening before. If copying fails the first time and "-B" is specified, the user will not get a warning message, and nano will silently retry at HOME. Maybe a warning message is desirable in this case. Should nano ask whether the user wants to proceed (and only then try again), or simply warn that the backup could not be created?

Thank you,
Michalis

(file #49383)

Michalis Kokologiannakis <michalis>
Thu 25 Jun 2020 05:28:50 PM UTC, comment #8: 

Oh, forgot to say: yes, I noticed most of the code was the same.  But I saw that in the Slowpath, when opening the original file fails, you set ret = 2, which results in a retry, but... with an 'original' that is NULL.  That will not work.  It will be much easier for me to see such cases of changed behavior if you don't move any code around.

Benno Schulenberg <bens>
Group administrator
Thu 25 Jun 2020 05:17:12 PM UTC, comment #7: 

Using the specified backupdir when the user has not specified -B/--backup is a problem, because the backupdir might be on a different device, it might be on a USB stick or something, and the user may want to write to it only under very specific circumstances.  So I don't want nano to write to it when not explicitly requested to do so.

The code to achieve that is simple: add a '!ISSET(MAKE_BACKUP) ||' in the 'if (backupdir == NULL)'.

When copy_file() to the designated backupdir fails (when both -B and -C were specified), there is no need to make a numbered backup in /tmp.  If the user-specified backup directory is not writable, this is a user error, and then the only reason we make a backup in /tmp is to be safe from crashes and full disks, so the backup can be just a simple tilded backup.

(For such a backup in /tmp, we should probably skip the chown() and chmod() calls, to make sure the file is not accessible for others.  Or maybe we shouldn't use /tmp at all?  Maybe such a safety backup should be made in the user's home directory?  Because no user ever will notice stray backup files in /tmp, but they probably will notice them in their home folder.)

Looking forward to your next iteration.  :)

Benno Schulenberg <bens>
Group administrator
Thu 25 Jun 2020 08:59:18 AM UTC, comment #6: 

Thanks for the feedback.

To clarify the refactoring a bit: get_backup() is the old code in the big if-statement that would make the backup in write_file(), while get_backup_name() is the part of the if-statement that would determine the backup's name. The code in these functions is largely the same as before, with the addition of a call to rename() in the beginning of get_backup(), and a loop that will call copy_file() again, if the first call fails.

As far as the usage of --backupdir is concerned, the patch does use the backupdir (if specified) even if the user did not specify -B but, in that case, the backup gets deleted afterwards. Is this a problem? I merely did that to keep the code that determines the backup's name as is.

As for get_backup_name() being called twice, this is because if the first backup with copy_file() fails, we will have to try again in /tmp. This is done in a loop at the beginning of which the name of backup is determined. (But, yes, it will lead to one extra call to get_backup_name() if rename() fails.)

I will follow up with another attempt within the next couple of days.

Thank you,
Michalis

Michalis Kokologiannakis <michalis>
Thu 25 Jun 2020 07:44:04 AM UTC, comment #5: 

Thanks for the patch.  But... too many changes in one patch -- I cannot follow any more what things you are changing.  It's better to not change any code that does not need to be changed to get the behavior we want.  It doesn't matter if the code becomes a mess: cleanups and refactorings can be done afterward.  In the patch I want to see only the necessary changes.

Some things about the procedure your proposed mechanism takes.

First, it uses the backupdir the user may have specified also when the user did not specify -B/--backup.  (Specifying -C/--backupdir does not imply -B/--backup.)  When -B/--backup is not specified, I think nano should leave the user's backupdir alone and should just use the tilded version of the file name for temporary backup.

Second, for a retry, it calls get_backup_name() a second time.  This should not be necessary.  Determining the name once should be enough.

(And as said in the beginning: the patch should not create a new get_backup_name() and backup_file() at all.  Change as little as possible, also whitespacewise.)

Benno Schulenberg <bens>
Group administrator
Wed 24 Jun 2020 04:51:35 PM UTC, comment #4: 

Ah, I see, thanks for the example.

I revised the patch (lightly tested again). Now rename() is used only in the fast path of the backup procedure.

Perhaps error handling is a bit awkward, but that should not be hard to fix.

Michalis

(file #49369)

Michalis Kokologiannakis <michalis>
Tue 23 Jun 2020 05:44:15 PM UTC, comment #3: 

There is another (not uncommon) scenario: editing a temp file in a temp directory, owned by root, that has the sticky bit set.  Renaming the original file to make a backup will not work there, but making a copy of the file will work.  For example:

sudo mkdir glued
sudo chmod a+tw glued
sudo touch glued/foo
sudo chmod a+w glued/foo
echo text >glued/foo
src/nano -B glued/foo

The above will work (will make a backup of foo in the glued/ directory) with current nano, but will fail to make a backup when using your patched version.

Compatability is of course a concern: backups should continue to work in all scenarios where it worked until now.  Crash-safety I have never considered -- I have not seen any user report such a case -- but would be nice to have.  Having it would also solve a problem that has been reported: losing the original file (because truncated to zero bytes) when the disk is full (bug #36864, bug #30786).

So... I think if renaming fails, nano should fall back to copy_file().  And if copy_file() fails (because the relevant directory is unwritable), then nano should copy the file to /tmp instead -- that directory should always be writable.  With that procedure, making a backup should always succeed (unless the disk is full, but that is fine: we still have the original file).  After that we can write out the current buffer as a new file under the old name.

The disadvantage of creating a new file (instead of truncating and writing to the existing file), is that we cannot restore the owner if the original file has a different owner than the current user.  Maybe this is not important, but... it is how nano has always worked, and maybe there are some people who expect the ownership of edited files not to change.

Benno Schulenberg <bens>
Group administrator
Tue 23 Jun 2020 09:57:47 AM UTC, comment #2: 

Good point, I did not think of that scenario.

So, AFAIU, the only case where the patch would make nano behave differently than before is if a user does not have write permissions on a directory and a --backupdir is used. Otherwise, both copying and renaming the file would fail. Is there another case I am missing?

The way I see it, there are two (orthogonal) problems: compatibility and crash-safety. As far as compatibility is concerned, while the patch does make nano warn that a backup could not be made in such cases, the problem is is that nano would fail to make a backup with the patch, whereas it would succeed without it. I do not know how often such a scenario occurs in practice, but I understand that you might want to maintain compatibility between versions.  As far as crash-safety is concerned, the failed rename() would make the save procedure crash-unsafe in the case you are describing, since the file would not have been backed up.  That said, plain copying would not help either.

Assuming compatibility is desired, one way to make the existing backup procedure crash-safe is to use fsync() after writing the backup, so as to ensure it has reached disk before truncating the original file. The reason I did not do that (and used rename() instead) is that copy_file() + fsync() is slower than rename(), and rename() saves some lines of code.

Another (more efficient) way to achieve both would be to use rename() as a fastpath, and only use copy_file() if rename() fails and --backupdir is specified. (One could also avoid using copy_file() if the user has not specified "-B" and silently fail, but that would still leave a tiny fraction of cases where there is a window that could lead to data loss, which could otherwise be prevented.)

Both fixes assume that a (temporary) backup needs to be taken anyway, and that "-B" is more of an indicator on whether the backup should be kept or not.

If you think it would help, I would be happy to send a patch with either one of the two fixes, or some other alternative you may have in mind.

Thank you,
Michalis

Michalis Kokologiannakis <michalis>
Mon 22 Jun 2020 05:56:14 PM UTC, comment #1: 

Hello Michalis,

Thanks for the patch.  I have always wondered why nano copied the existing file in order to make a backup when the file is already there.  But... maybe it is to account for this one possibility: the original file is readable and writable but not deletable (by the current user)?  When the file is not deletable, rename() would fail, but copying the file would work fine (for sure when --backupdir is also used), and truncating and rewriting the file with the updated data would work too.  What is nano to do when the original file is undeletable?

Benno Schulenberg <bens>
Group administrator
Mon 22 Jun 2020 04:36:41 PM UTC, original submission:  

Hello,

While experimenting with nano, I noticed that the behavior of nano during save (especially when overwriting existing files) could lead to data loss under ext4.

There are two issues with the current save procedure:

    1) It is not guaranteed that after saving (or exiting and saving) the file's data will be on disk.
    2) When overwriting existing files, there is a window in which the original file has been truncated and the new file is not on disk yet. Under some circumstances, a crash during this window could lead to data loss, even if nano's "-B" option is used.

As far as the first issue is concerned, the problem is that there is no call to fsync() after the fwrite()s of the buffer in nano's write_file().  This means that if, for example, I open an existing file, make some changes, press ^X and then save the modified buffer, there is no guarantee that the contents of the file will have been written out on disk when nano returns control to me, so I may end up with a file of a much smaller size.

I think it's counter-intuitive to lose data from an existing file simply because the file was edited (and hence truncated during save). And while ext4 does try to catch patterns where a file has been opened with O_CREAT|O_TRUNC, and starts flushing out data on close() (see auto_da_alloc @ ext4(5)), neither does close() wait for the data to be flushed before returning, nor does ext4 flushes the disk's cache.

Of course, one could argue that even using fsync() wouldn't prevent data loss if the machine crashes during fsync(), which is true. I think that nano should either make a temporary backup file, or just make the "-B" option the default, and have the user explicitly turn it off.

Which brings up the second issue, namely that the backup procedure currently used when a file is edited with "-B" is not crash-safe either. The backup is created using read(), open(O_CREAT|O_TRUNC), write(), and close(), a sequence that suffers from the same problem described above: since there's no fsync(), it is not guaranteed that the backup file has reached disk when we start writing out the real file. So we could end up with a partially written file and a partial backup.

I managed to reproduce the above issues using nano v3.2 (default in Debian buster) and a recent git version of nano (commit d8249917). To reproduce them, one needs to trigger a race with the jbd2 kthread (e.g., w/ some synchronous disk I/O) so that jbd2 commits the transaction with the file truncation, as well a crash before the written data is flushed (this can occur even after nano returns). That's easier to do with large files (e.g., >= 128MiB).

Please find a patch with a proposed fix attached (lightly tested; probably some more error checking is necessary). In the patch, I am making a temporary backup unconditionally using rename() (rename() is probably faster compared to the existing copy_file() anyway, but also safer from a durability perspective), which will get deleted if the user hasn't specified "-B". I am also using fsync() to make sure that data has reached disk after save returns.

Thank you,
Michalis

Michalis Kokologiannakis <michalis>

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by michalis (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.

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-30 bens Open/ClosedOpen Closed
    2020-07-26 michalis Attached File- Added editor-interactive.sh, #49549
    2020-07-09 bens StatusIn Progress Fixed
    2020-07-04 michalis Attached File- Added v2-0001-files-improve-the-backup-procedure-to-ensure-no-d.patch, #49422
    2020-07-03 michalis Attached File- Added v2-0001-files-improve-the-backup-procedure-to-ensure-no-d.patch, #49420
    2020-07-02 michalis Attached File- Added v2-0001-files-improve-the-backup-procedure-to-ensure-no-d.patch, #49407
    2020-06-30 bens Attached File- Added 0001-files-improve-the-backup-procedure-to-ensure-no-data.patch, #49396
        Assigned toNone bens
    2020-06-29 bens Attached File- Added 0001-files-improve-the-backup-procedure-to-ensure-no-data.patch, #49394
    2020-06-29 michalis Attached File- Added 0001-fixup-files-improve-backup-procedure-to-ensure-no-da.patch, #49385
    2020-06-29 bens StatusNone In Progress
        SummaryPotential data loss under ext4 when overwriting files potential data loss when overwriting existing files
    2020-06-29 michalis Attached File- Added 0001-files-improve-backup-procedure-to-ensure-no-data-is-.patch, #49384
    2020-06-29 michalis Attached File- Added 0001-files-improve-backup-procedure-to-ensure-no-data-is-.patch, #49383
    2020-06-24 michalis Attached File- Added 0001-files-improve-backup-procedure-to-ensure-no-data-is-.patch, #49369
    2020-06-22 michalis Attached File- Added 0001-files-ensure-no-data-loss-under-ext4-when-saving.patch, #49347

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code