Copying large files to flash USB memory stick needs UI improvement

[tethragon]

When you copy large files (i.e. live iso linux images) to a USB flash memory stick, a file transfer window opens to show the progress of the copy and closes (pretty fast) when the data are copied to the cache (NOT the actual USB). So the user believes that the file copy operation has been completed and the file has been transferred to the USB successfully. However data in the cache are still NOT written in the USB and the actual file copy process could go on for several minutes, This could lead to file corruption if the user tries to pull the usb, or restart the system (i.e. to try its "written" iso).

The user wants to copy a file to USB, therefore he/she should be informed about when the file transfer has been written to actual USB and not the cache.

I believe there should be a change in the way that the file manager informs the user about a file copy operation. Maybe the progress bar window closes when the actual data are written in the usb and not the cache?

This video showcases the problem --> https://www.youtube.com/watch?v=a1V6kE3jDhs

[leigh123linux]

There are warnings if you use the eject media button.
It's the same in Windows.

https://www.stellarinfo.com/blog/why-do-you-need-to-safely-eject-the-usb/

[tethragon]

There are warnings if you use the eject media button.
It's the same in Windows.

Is this an excuse? Why do we use Windows as excuse when something is not "right" both in Linux and Windows? I firmly believe that the user friendly solution is the file copy dialogue to be transparent to the user and inform him when actually the copy has finished (to the usb, NOT the cache). Unless this is not possible... I've been helping many users and the file corruption is something that happens often, because of this bogus file copy dialogue. The user wants to copy a file to USB, therefore he/she should be informed about when the file transfer has been written to actual USB and not the cache. The user may not know what cache is and how it works.

[leigh123linux]

Maybe users should learn to use their computers correctly instead of blaming the app!

[tethragon]

Maybe users should learn to use their computers correctly instead of blaming the app!

I do not agree with this attitude. 99% of the users are non technical and this won't change. That's why we have GUIs with the main goal being as user friendly as possible.

[tethragon]

I think the solution is very very easy:

When a file is copied to cache, therefore the progress bar reaches 100% and closes, the file manager should run a "sync" command in the background and wait for it to end without errors. Then the file manager can inform the user that the file transfer to USB is complete.

[Jeremy7701]

A sync command would force out all outstanding writes for multiple applications.

[leigh123linux]

Maybe users should learn to use their computers correctly instead of blaming the app!

I do not agree with this attitude. 99% of the users are non technical and this won't change. That's why we have GUIs with the main goal being as user friendly as possible.

There will always be people that are too dumb to use computers.

I think the solution is very very easy:

When a file is copied to cache, therefore the progress bar reaches 100% and closes, the file manager should run a "sync" command in the background and wait for it to end without errors. Then the file manager can inform the user that the file transfer to USB is complete.

You are free to investigate and submit a 'pull request' to address the issue.

[tethragon]

A sync command would force out all outstanding writes for multiple applications.

How is that different than "safely remove drive" ?

What about fsync? I think this one syncs only a file.

[tethragon]

You are free to investigate and submit a 'pull request' to address the issue.

Sir, I know that. I have programming skills (have developed a couple of android apps in the past) but I am not a professional programmer and I would have to quit my day job to do what you asking. Is this forum only for people who submit "pull requests"? I do not think so. We can report what we think is an issue, and if developers are convinced, then they fix the problems. I can understand if what I am asking is not considered a problem by the developers, but your attitude is not good.

[SergiusTheBest]

@leigh123linux

There are warnings if you use the eject media button. It's the same in Windows.

https://www.stellarinfo.com/blog/why-do-you-need-to-safely-eject-the-usb/

Windows mounts external drives with write caching disabled, so a file is really written to the disk and you can eject it almost immediately after a copy dialog closes:

[SergiusTheBest]

@Jeremy7701

A sync command would force out all outstanding writes for multiple applications.

The command can be sent to a file descriptor, so only that file will be affected: https://man7.org/linux/man-pages/man2/fsync.2.html

Windows mounts external drives with write caching disabled

Same thing could be implemented overall in Mint if it had a centralized structure, using flush in the mount command automatically for removable drives (see the link below). Unfortunately it doesn't have a centralized structure - that is, the mount command can be called from various pieces of code or manually from the terminal, which would require the manual use of the parameter(s) - so it could at most be implemented on an app by app basic.
Unless the mount command itself would be redirected through an additional piece of code that would determine the removable nature of the drive and would apply such specific flags dynamically based on user-defined preference in a GUI panel. But I don't see that happening anytime soon, if ever.

So one may have to make do with the next-best thing, which would be using hdparm (if available) to disable write cache manually on each removable drive after each (re)mount:
sudo hdparm -W 0 /dev/devicename
as mentioned here. That should provide an accurate visual feedback on the operation.

[tethragon]

Windows mounts external drives with write caching disabled

Same thing could be implemented overall in Mint if it had a centralized structure, using flush in the mount command automatically for removable drives (see the link below). Unfortunately it doesn't have a centralized structure - that is, the mount command can be called from various pieces of code or manually from the terminal, which would require the manual use of the parameter(s) - so it could at most be implemented on an app by app basic. Unless the mount command itself would be redirected through an additional piece of code that would determine the removable nature of the drive and would apply such specific flags dynamically based on user-defined preference in a GUI panel. But I don't see that happening anytime soon, if ever.

So one may have to make do with the next-best thing, which would be using hdparm (if available) to disable write cache manually on each removable drive after each (re)mount: sudo hdparm -W 0 /dev/devicename as mentioned here. That should provide an accurate visual feedback on the operation.

This is not a solution, rather a circumvention. What about nemo issuing a sync or fsync command after the file is copied to cache? There is no drawback in that. The file copy dialogue would stay open until the sync command is finished.