Safely remove is causing data loss

Bug #1904790 reported by Ritchie Miller
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
dolphin (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

In short

When you do "Safely remove" on a removable device like USB stick in Dolphin file explorer, it does not guarantee you can safely remove it from the port. It does not wait till true copy completion.

Longer story

I was shocked last weekend when I went to my sister with a USB stick to show her some photos of mine. We've been watching them and suddenly at ~40% of the slideshow, a message started showing up saying that the TV can't read the file. The case was for the remaining 60% of the photos. Sadly we stopped. At home I checked that and indeed the rest of the files were corrupted.

I tried to replicate this several times:

    1. Start copying files to the USB stick (~3.5GB of photos).
    2. Wait until copy notification of 100% done.
    3. Click "Safely Remove" on USB stick in KDE's Dolphin File Explorer.
    4. Remove USB Stick from the port (BOOM! Data loss).

I couldn't believe that, but this behaviour is consistent. At first I was using a USB stick without a usage LED indicator, so I couldn't say if it is busy on the hardware level. Then I switched to an old Kingston USB stick with LED, and after step 3 (Click "Safely Remove" on USB stick), the usage LED was blinking for a few more minutes!!!

Reason

I've searched the net and this problem seems to be related to how Linux kernel buffers write operations to removable devices. There are suggestions out there mostly to reduce dirty_bytes kernel parameter value, but I think this is not a solution. Giving the user an impression that now he can safely remove the stick while in reality the copy process is in progress is a no-go. KDE apparently is being given a false sign from the kernel that the copy process is completed. But it is finished only from the shell's perspective. At the point of 100% done shell notification, it has just been fully moved to write cache. Then the kernel writes it slowly at real USB stick transfer speed to true completion. That is my understanding.

Temporary solution

The only solution I have found for now that works is the sync command. Before pulling out the USB stick, just call sync in the command line. That flushes all the buffers and waits until truly done. I confirmed that with the usage LED indicator on my Kingston stick. The LED stopped blinking right after the sync command returned.

Solution

That is the task to do. Please fix this issue as this is a very basic, common use case of the file explorer.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: dolphin 4:19.12.3-0ubuntu1
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.12
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Wed Nov 18 21:35:32 2020
InstallationDate: Installed on 2020-10-18 (31 days ago)
InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
SourcePackage: dolphin
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Ritchie Miller (ritchie-miller) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in dolphin (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.