It has come to my attention that Files version 43.0 removed the size of a file in bytes when you open it’s properties. Do I really need to open my terminal everytime I want to check a file size? In my very humble opinion, this is removing things that were just fine.
As you can see, the new properties window only show the size in a “human readable way”… But now if you need the size in bytes you must open a terminal. Is this a bug or just a regression?
In Files 42.2, with the old properties window, it would show the human readable size and the size in bytes.
That’s… nice to know I guess… Wouldn’t have found out soon if it weren’t for you. Definitely a regression in my opinion, but I’m happy to know that I’m still able to see it. For a moment I thought we were going a path that’s so into minimalism that we’d removed the size.
We’ve added the tooltip with exact number of bytes just because it was possible and that information used to be displayed in previous version. So, I just assumed that someone somewhere would find it useful. But honestly I can’t see a use case.
My daily driver is Fedora Workstation and therefore Gnome, I use it at work and at home.
Now for example I’m writing a driver for an SD Card… and to check whether a part of it was working I was constantly inserting, checking, formatting and removing it from the computer. When inserting the disk, I click on the gnome desktop’s notification and enter the folder, and to avoid having to open the terminal and type “ls -l”, I was relying on the properties window, but I want to know the specific size in bytes which is now hidden.
So first, could I change my workflow there? Yes, definitely, but if it wasn’t broken on Files 42.2, it probably should not be on 43.
Second, it’s now harder to know the exact size than it was before because:
There’s honestly nothing that indicates I can hover my mouse over the human readable size. I’d really not
have found out if it weren’t for jensgeorg.
When you do show the size after the hover, you don’t use the thousands separators.
Before:
Mouse to Notification → Click → Mouse to Directory → Click → Mouse to File → Click → Read it.
Now:
Mouse to Notification → Click → Mouse to Directory → Click → Mouse to File → Click → Mouse to Size → Read it without the thousand’s separators.
Just the fact that I need to get the cursor above the little text is actually enough for it to be annoying.
Now don’t get me wrong, I think the new interface is beautiful… This is in fact the only thing that got me worked up about the desktop up to this day. I considered applying a patch and build my own “Files”.
It’s not actually a kernel driver. I’m an embedded developer, it’s an SD card driver used by a firmware. Either way, yes, it’s not unreasonable… And I actually spend most of my time on CLI…
It’s just that in this scenario I find it faster to click on the desktop notification and show the properties of the file.
Then, maybe for your use case the most useful thing would be writing an extensions which adds a new column to the list view to display size in bytes for every file in the directory.
That’s cool, I’ll probably take a look or build my own nautilus.
Either way, I’d definitely consider at least adding digit separators to the size that shows up after hovering the human size, it’s currently hard to find and hard to read.
In Gnome’s settings, my language is set as “English (United States)” and formats as “United States (English)”. It should use commas as separators, but it doesn’t.
I guess we are not taking the locale into account when making this size a string.
Btw, I just found out that France’s Format doesn’t use separators… I had though the entire world used it.
I had noted the change too but I saw this discussion only now. I want to bring my take on this:
In my workflow I often make backup copies of files, and comparing the exact number of bytes for checking if there is already a backup of the current version of a file is faster than launching diff on a terminal. Without the exact number of bytes that becomes impossible.
I am happy to find out that there is a tooltip (so, problem solved), but I have to confess that I would have never found out about it without reading this thread (and I would have probably considered it a regression too).
For your user case, I would suggest an extension which provides hashes of the files. Hashes provide an even better way to make sure tge file contents are the same.
Edit 0: Earlier I got the source for the older version of nautilus and it didn’t work.
Edit 1: This only calculates the MD5 of the filename, not it’s contents. Don’t know if it’s useful.
