Version: unspecified (using KDE 4.7.3) OS: Linux I really like Dolphin but it is 2 things that I miss: 1) Dedicated Creation date and Modification date columns for files and folders (Same as MS Windows). I am never sure what "Date" is for. 2) A size column which show the folder size too. Somebody wrote that for MS Windows (GNU/GPL) but think about Linux (http://foldersize.sourceforge.net/about.html) easier Those 2 things makes files and folder management easier and faster. Reproducible: Didn't try Expected Results: Wish list
1) Unix file system do not record the file creation date. 2) The size of a folder has to be computed by recursively scanning all files, which would be very slow.
Thank you for your quick feedback 1) Thank you as I didn't know that event I think that it should be a useful info. 2) I know that can make a PC slower but if it is an option why not. I am able to make it work without speed issue on an old 2006 laptop which was not the best then, using Windows XP... Nowadays, PC are quite faster and more and more geek/linux user PCs got more 8Gb RAM. It is great to catch empty folders quickly and check bloated folders too!
Hi I am coming back about the folder size feature as I have just seen a preview of Dolphin 2.0 on KDE 4.8. You told me that this idea was bad because it will make the process very slow. 1) I told you that I never had to complain about the speed using it on a 6 year old PC and that actual computers will easily cope with that. It can be useful too. 2) Today, I can see that you worked on "Animated Transitions" for Dolphin which are nice but totally eye-candy... I believe that users rather need KWin/Compiz 3D effects on their system than useful features. I understand that Linux DE should be pretty as possible to seduce more users from Windows and Apple wolds. I also prefer pretty software above other. By the way, Dolphin is the prettiest file manager for Linux. So I got it. I can forget that feature and spend my time rotating my desktop cube forever. Nothing personal here; just a complain about a general flaw in the IT world...
> You told me that this idea was bad because it will make the process very slow. Christoph did not say at all that "this idea was bad", he just (correctly) claimed that it is slow. To get an impression: Select the folder "/usr", do a right-click and select "Properties" and watch the Size-value. It takes ~1 minute on my old notebook until the value has been determined. During this minute the harddisk is constantly working. It might not be no issue in your working environment because you probably don't have that many nested folders or don't have much application running in parallel, but for other users this might be an issue. In my opinion applications like "filelight" do a better job to detect huge folders and should be used instead. > So I got it. I can forget that feature and spend my time > rotating my desktop People that are working on rotations and animations probably won't be able to implement your feature-request at all. If there are more people out there who find your feature-request useful there most probably also will be a developer that implements it. Whether your feature-request will be implemented or not is totally unrelated to whether someone implements animations or not.
I know that nobody can't do everything. Even I can produce some VBA code; other languages are out of my skills. It was more about priorities... Eyes-candy against other features. Believe me when I say that it was fast enough. I guess that's will take time from root folders. I reckon that showing it from the root (c:\) took some time but as it was parallel tasking and I've got some folder before others and once all sub folders scanned a right click on the property show me the correct value without delays. It's also seems to keep track of folder size until the Explorer session is closed. I believe that it was storing this value somewhere. I am going to link this thread to the person who wrote this feature. I know that he was thinking about Linux at some stage. I hope that it still the case. Can it be written as plugin? Thanks for your feedback.
> Can it be written as plugin? No, for this usecase this is not possible (yet) in Dolphin.
Resetting assignee to default as per bug #305719
The sidebar in Dolphin (4.11.5 in Netrunner) shows both Modified timestamp and Date Time Original. This is on image files. It would be very helpful to be able to show Date Time Original in Detail mode alongside the Modified timestamp. I have read in a number of places that creation date/time is not held, but simehow Dolphin sees a timestamp that I know to be just that. These images have been taken off a camera, and some have been rotated, which changes the date/time shown.
Regarding Foldersize: I know it would slow down a system, when the size of folders is calculated permanently. How about a compromise: Add a function to Dolphin (or another file-mager), which calculates the foldersizes (including sibfolders) in the recent folder. It would be very nice, if we could sort the folders by size. Just have a look at the recent FreeCommander for Windows and you'll know what i mean. Afaik, this is the only Filemanager for Windows with this option. I am also aware about the fact of the "FolderSize-Service", which worked well under XP, caused a lot of systemload, similar to an indexing-routine. We could skip this problem by making the displaying of the foldersize switchable. Kind regards JD
I'd just like to add that this would be a very useful feature. My main use case is I have a directory tree I'd like to sort through and delete any large files/folders in order to free up some space or to reduce the size prior backing up/transferring to other media. Currently this requires the tedious process of selecting groups of folders, opening properties to get the total size, then subdividing the search into smaller groups of folders, until I can drill down one level and rinse and repeat with another group of folders. Using du is not a great solution due to the flattening of the tree structure in the output. It would be much easier with the hierarchical view provided by file managers such as Dolphin where I can start by opening the largest folder, then the largest subfolder, etc until I quickly find the space hog - usually a DVD ISO I forgot to delete. Obviously automatically finding the size of all folders would be a bad idea. The way I envision this feature would work would be something like right-click on a folder and select "show folder size". At this point Dolphin finds (and remembers) the size of all folders in subtree under the selected folder. Dolphin could display something in the folder size column to indicate it is still computing the size. The user can then browse down into subfolders of this folder and see the size of each folder. Once Dolphin has read and cached all the sizes this should quick and much more usable than having to open properties on each folder. The user could do the same with any other folder in the filesystem and Dolphin continues to cache subtree folder sizes in all the "folder size enabled" subtrees. When exiting Dolphin the cached sizes are lost so the user will need to enable them again next time. Dolphin could also have a global "stop reading folder sizes" menu option to release all cached sizes. As for performance I don't think would be too bad. I brought up properties on one of my larger trees. It took less than 15 seconds to total up 2TB in 250,000 files and 30,000 sub-folders. This is on a 7200rpm disk.
Thank you, ultrajej@yahoo.fr, for this excellent bug report/feature request. 1) In Dolphin, if the folder is listed under "Places", folder size is viewable by clicking on the folder in "Places". This functionality ought to be ported to the folders themselves. We should be able to hover the mouse and see folder size/number of files. This would not require much coding or resources. It might also be helpful if, for example, empty folders were indicated with a slightly different appearance/colour tone. T 2) Being able to sort files by date downloaded/ created on the computer is an excellent suggestion. This commonly used functionality is available in M$ft, it ought to be available in Dolphin. GNU+Linux keeps logs, these could perhaps be used as a basis for a "Created" column. Some KDE applications, for example Digikam, already handle "Date Created" for photo files, and have done for some time, so code is already available. I hope that both these bugs are fixed. They are expected features in a file manager, as far as I am concerned.
Accessing the file creation date is now possible for ext4 as of Kernel 4.11, via the statx system call.
*** Bug 374063 has been marked as a duplicate of this bug. ***
*** Bug 381334 has been marked as a duplicate of this bug. ***
*** Bug 358075 has been marked as a duplicate of this bug. ***
Dolphin already shows file modification dates in a column. To avoid overloading this bug, let's use it to track adding creation dates (when available), and use https://bugs.kde.org/show_bug.cgi?id=158090 to track computing folder sizes.
⚙ D6243 Add role for file creation time. <https://phabricator.kde.org/D6243>
When dolphin shows the mtime already, what is about the atime (access time) then? Would be also good to have the possibilty to seen when the last access was.
Thanks for that change, Graham! It looks like we'll need to get UDS_CREATION_TIME populated on supported Linux systems right? For that, I've filed https://bugs.kde.org/show_bug.cgi?id=381367
>> … To avoid overloading this bug, let's use it to track adding creation dates (when available) … (In reply to Christoph Thielecke from comment #18) > … atime (access time) … I suggest a separate bug for atime. ---- (In reply to Nate Graham from comment #19) I don't know about Linux, sorry, some of what I linked to came to my attention following chat in <irc://chat.freenode.net/#kde-freebsd>.
*** Bug 381367 has been marked as a duplicate of this bug. ***
I've submitted a patch to make this work in Linux: https://phabricator.kde.org/D7423
(In reply to Graham Perrin from comment #17) > ⚙ D6243 Add role for file creation time. > <https://phabricator.kde.org/D6243> I'm closing this report, since there is nothing more to do from the Dolphin side.
*** Bug 311552 has been marked as a duplicate of this bug. ***
Git commit 5f2ab5c62dd56e5a1dae468355c9e72d84d94398 by Méven Car. Committed on 14/04/2019 at 13:36. Pushed by meven into branch 'master'. Allow the baloo widgets to display creation date and access date. Summary: New fields accessed and created in dolphin/baloo-widgets information panel: {F6761789} GUI: New fields accessed and created in dolphin/baloo-widgets information panel Test Plan: Tested locally Reviewers: ngraham, elvisangelaccio, bruns Reviewed By: ngraham, elvisangelaccio, bruns Subscribers: bruns, #baloo Tags: #baloo Differential Revision: https://phabricator.kde.org/D20404 M +9 -0 src/filemetadataprovider.cpp https://commits.kde.org/baloo-widgets/5f2ab5c62dd56e5a1dae468355c9e72d84d94398
Very, very much thanks! Am 14.04.19 um 15:36 schrieb Méven Car: > https://bugs.kde.org/show_bug.cgi?id=286689 > > --- Comment #25 from Méven Car <meven29@gmail.com> --- > Git commit 5f2ab5c62dd56e5a1dae468355c9e72d84d94398 by Méven Car. > Committed on 14/04/2019 at 13:36. > Pushed by meven into branch 'master'. > > Allow the baloo widgets to display creation date and access date. > > Summary: > New fields accessed and created in dolphin/baloo-widgets information panel: > {F6761789} > > GUI: New fields accessed and created in dolphin/baloo-widgets information panel > > Test Plan: Tested locally > > Reviewers: ngraham, elvisangelaccio, bruns > > Reviewed By: ngraham, elvisangelaccio, bruns > > Subscribers: bruns, #baloo > > Tags: #baloo > > Differential Revision: https://phabricator.kde.org/D20404 > > M +9 -0 src/filemetadataprovider.cpp > > https://commits.kde.org/baloo-widgets/5f2ab5c62dd56e5a1dae468355c9e72d84d94398 >