4 ms·

I'm afraid the issues I describe have been with Ubuntu. Here's the first line from my "linux sins" file as an example: https://askubuntu.com/questions/115128

I'm afraid the issues I describe have been with Ubuntu. Here's the first line from my "linux sins" file as an example: https://askubuntu.com/questions/1151283/disable-nautilus-caching-mechanism https://askubuntu.com/questions/1151283/disable-nautilus-cac... If you copy a large file to a USB drive on either Ubuntu or Mint the progress bar goes to 100% instantly and closes and the actual transfer of the file is done in the background without the knowledge of the user. And the answer is "It's your fault, just try to eject the drive until it works." And even beyond the OS, the whole software ecosystem is broken. It's impossible to find simple, working UIs for the most basic pieces of software, everything goes through the commandline.

Alupis 6y ago
Fair enough, but I'd just like to point out that specific issue you linked to happens on Windows too (and almost certainly MacOS as well). It's just how device writes work, and is why Windows users have been told for years to select their device -> Eject instead of just yanking the USB drive out when Windows says 100%. So, not exactly a fair criticism in my opinion, but your overall point stands - Linux can be rough around the edges for some use cases.
- ad404b8a372f2b9 6y ago
  It doesn't happen on Windows because the cache is made to be small enough that the caching and flushing happen at the same time regardless of the size of your RAM. So your transfer progress bar will end at approximately the same time as the actual transfer. I don't use MacOS but I assume they have the UX & UI figured out as well. That's not the case on Linux, the progress bar will disappear in seconds while the transfer can last hours. And, I say this with no ill-will toward you, I'm not trying to be antagonistic but you're having the same response as all linux users I encounter online. You're denying the problem even exists, saying it's not fair and it might be rough for some use cases? This is transferring a file to a USB stick, this is a very basic use case, and the UI is broken and the UX is dogshit (excuse my french). If we can't admit there is a problem we're never going to get around to fixing it.
- yellowapple 6y ago
  > I'd just like to point out that specific issue you linked to happens on Windows too The poster of the question explicitly states that this behavior does not happen on Windows using the same hardware. And indeed, Windows doesn't cache as aggressively as Linux does (which is one of several reasons why Linux tends to have better disk performance and less risk of disk fragmentation), so no, by design, this issue is more pronounced on Linux. The actual reason why Windows users are told to explicitly eject instead of just yanking the device is because there are various background processes that might be writing to the device (particularly relevant if you're using SpeedBoost or whatever it's called), not because of file copy progress bars being entirely unaware of the OS' caching mechanisms.
alanbernstein 6y ago
I have had gripes about usb drive writing in the past, but what you describe does not happen in my install of Ubuntu 20.04.
- ad404b8a372f2b9 6y ago
  It depends on the size of your RAM as far as I understand the issue.

Alupis 6y ago

Fair enough, but I'd just like to point out that specific issue you linked to happens on Windows too (and almost certainly MacOS as well). It's just how device writes work, and is why Windows users have been told for years to select their device -> Eject instead of just yanking the USB drive out when Windows says 100%. So, not exactly a fair criticism in my opinion, but your overall point stands - Linux can be rough around the edges for some use cases.

ad404b8a372f2b9 6y ago
It doesn't happen on Windows because the cache is made to be small enough that the caching and flushing happen at the same time regardless of the size of your RAM. So your transfer progress bar will end at approximately the same time as the actual transfer. I don't use MacOS but I assume they have the UX & UI figured out as well. That's not the case on Linux, the progress bar will disappear in seconds while the transfer can last hours. And, I say this with no ill-will toward you, I'm not trying to be antagonistic but you're having the same response as all linux users I encounter online. You're denying the problem even exists, saying it's not fair and it might be rough for some use cases? This is transferring a file to a USB stick, this is a very basic use case, and the UI is broken and the UX is dogshit (excuse my french). If we can't admit there is a problem we're never going to get around to fixing it.
yellowapple 6y ago
> I'd just like to point out that specific issue you linked to happens on Windows too The poster of the question explicitly states that this behavior does not happen on Windows using the same hardware. And indeed, Windows doesn't cache as aggressively as Linux does (which is one of several reasons why Linux tends to have better disk performance and less risk of disk fragmentation), so no, by design, this issue is more pronounced on Linux. The actual reason why Windows users are told to explicitly eject instead of just yanking the device is because there are various background processes that might be writing to the device (particularly relevant if you're using SpeedBoost or whatever it's called), not because of file copy progress bars being entirely unaware of the OS' caching mechanisms.

alanbernstein 6y ago

I have had gripes about usb drive writing in the past, but what you describe does not happen in my install of Ubuntu 20.04.

ad404b8a372f2b9 6y ago
It depends on the size of your RAM as far as I understand the issue.