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.
The size in bytes is available as a tooltip if you hover over the human readable size:
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.
The type has got a tooltip too, which reveals the MIME type
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.
So, would you mind explaining why you find it useful and important to have?
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.
Mouse to Notification → Click → Mouse to Directory → Click → Mouse to File → Click → Read it.
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”.
Thanks for explaining!
I’d say that writing and testing a kernel driver is a use case where using the command line is not unreasonable.
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.
Oh, right, I forgot that point. I believe it depends on your locale settings whether to display numbers with separators and which separator is used.
In theory it should.
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’ve fixed the issue. Now the tooltip shows thousands separators depending on the locale: https://gitlab.gnome.org/GNOME/nautilus/-/commit/21a6a7ed12d78f6d972e17d91820270c08e201a6
43.2 is going to include this enhancement.
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).
Awesome! Thank you for your hard work and your attention
Thanks for your input.
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.
I mean, i recall one such extension. I don’t know whether it has been ported to libnautilus-extensions-4.
This extension? https://gitlab.gnome.org/GNOME/nautilus-python/-/blob/4.0/examples/md5sum-properties-model.py
It runs just fine.
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.