You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Nemo does not update empty folder status after moving a file #2537
* Nemo version 4.6.5
* Is issue with desktop or windowed nemo?
* Distribution - Linux Mint 20 Ulyana
* NVIDIA GeForce RTX 2060 | Driver: 450.80.02
* 64 bit
Issue
If you have an empty folder in List view and move a file into it, Nemo still indicates that the folder is empty. The arrow to the left showing the folder's contents will not appear until you re-open or refresh the directory containing the now non-empty folder.
Steps to reproduce
Have Nemo open in List view.
Navigate to a directory with an empty folder or create an empty folder.
Move a file into the empty folder. This can be a newly created file.
The folder still shows that it's empty.
Expected behaviour
After moving the file inside the folder, the folder updates to show that there is now a file inside it.
The demonstration is in list view; not icon view (as specified in the problem description).
I tried to reproduce the problem in both icon and list view but couldn't reproduce the problem.
Yes, I noticed this as well. In list view the folder should have a little arrow next to it that you can use to expand the contents if the folder is not empty. When you drag something into an empty folder, no arrow appears. But it will appear if you reload the view (Ctrl-R). It's hardly the worst bug ever but probably worth pointing it out nonetheless.
No extra info is needed. We're aware of this issue, but it's not trivial to fix. I'm considering reverting back to always showing the arrow, whether empty or not.
Thanks for the update @mtwebster. Do you mind sharing some technical information on why it's not trivial? To my understanding, when a file is moved into a folder successfully, the folder can never be empty, and I'm wondering what could be the underlying problem displaying an arrow in this case.
This bug is very irritating when manipulating large projects. If I have a set of folder opened multiple layers deep, when I refresh, it collapses the whole tree structure and I have to reopen all the folders, remembering which ones were opened. Always showing the arrow would be a good solution for me.
I think this is a fairly insignificant bug as you would know anyway that the directory isn't empty if the just moved stuff there. I find the way it currently works is far better than always showing the arrow as that provides far less information and you'd always be trying to expand folders only to find them empty which I think is far more irritating and probably so to far more people.
@fredcw I think the more important problem is (for me at least it is) that you can't tree-expand the folder after moving something into it. Indeed I agree, I am not too fond of having the arrow always showing either.
@gkatev I agree, keeping the folder structure expanded after refresh would be a good solution.
@fredcw The issue is not about knowing if the folder is empty but rather viewing the files in it. You can't see the files if you can't expand the folder structure. This is a real pain when the folder structure is generated. Every time I trigger a re-generation, I have to refresh the folder. If my objective is to compare the generated files against previous generations, I will have to refresh and re-expand the folder structure of the previous generations after every single attempt. NOTE: The generated folder structure is often really deep, like 10 folders deep. If the arrow was always showing, I would not need to refresh and would not need to re-expand the folder structure of the previous generations. That might seems like a very isolate case, but I'm facing this issue several times a week.
@Jeremy7701 Never showing the arrow would break the tree view feature in list view. You would not be able to expand a folder in list view.
I have the same irritation. Keeping the folder structure expanded after refresh would be my preference. If that is difficult then displaying the arrows on all folders would be reasonable compromise; including the size column informs the user if the folder is empty.
I'd still like to understand the technical issues regarding this bug. Is it not possible to refresh just a single folder and/or keep the tree view intact on refresh?
I'm wondering why it'd be required to settle for anything less than the expected behavior from users. Other operating systems do not have this issue. @mtwebster would you please provide us with more details?
Only the active folder gets monitored for changes.
The current directory is loaded. While loading any child directories get their contents counted (first-level only) so those counts can be displayed.
If the addition/removal of a file from a listed folder is performed by nemo, the change will be seen, and arrow updated, because that folder will have been loaded to perform the transfer. Same if you have the listed folder open in another view elsewhere.
If the change is done from another program or terminal, the change will go unnoticed, unless the folder is also open in nemo somewhere.
When you click the arrow to expand the contents of a folder, at that point step 1 occurs to that folder - its children counted one level deep, arrows reflecting contents, etc..
..and so on..
Originally in nemo, all items had an arrow, empty or otherwise. When you clicked the arrow, it would be updated to say 'empty' or would briefly say 'loading' before displaying the folder's children.
Adding monitors to the current directory's children could end up having huge performance/memory implications, plus issues with mounted remote folders (which might not be detected).
I've considered, and talked about going back to that old behavior - always arrows, because at least it would be consistent. To be honest at the time I didn't realize the potential issues here myself or I wouldn't have changed this to begin with.
ps. There's a bug fix for crashes when expanding out-of-date folders that hasn't made it live yet.
I have a quick "workaround" that may be acceptable for some:
Drag the folder in question to a neighbouring folder
Press Ctrl-Z to undo the move - the folder will now have its arrow to allow it to be expanded.
In this way the tree structure is not collapsed as would be the case with a "refresh" operation.
The @BNIslander "workaround" is a bit tricky but it works. I'll use it till someone fix the bug another way because it also annoys me a lot.
I totally agree with you.
I have a edge case where I can't move the folder as suggested. The folder is auto-generated by an app I'm developing. The creation of all the files in the folder take about 10 minutes. If I move the folder half way through, the app will crash since its output folder will cease to exists. I need to see the files as they are getting generated to know if it's progressing well and to know when something goes wrong.
The only workaround that works for me is pressing F5, but that's just another annoyance. The generated folder tree structure is about 10 folder deep (the app generates a LOT of files). Pressing F5 close the whole tree structure and I have to navigate again to the folder I was looking at. That gives me headaches...
Just to add some context, the app I'm developing is generating videos from raw NetCDF data files. First step is to generate the video frames (images). Then it combines the frames to create a video. The raw data file contains a multi-dimensional array of data (longitude, latitude, depth, time, hundreds of variable). The large tree structure is necessary to separate the video frames by depth, time range and variables.
This is obviously an edge case, but that issue also annoys me every day, whatever I'm doing. Except the F5 trick works for me most of the time. It's just in that edge case where there is no acceptable workaround.
@gaellafond
Yes, your case it's a bit on the edge.
Nevertheless I think that as it is now, the Nemo behaviour is incorrect.
The optimum would be no arrow when the forder is empty and a arrow when something enters the folder.
Anyway I agree that this solution can carry some development issues.
So any of the other proposed solutions would be better than the one we have now.
But we have to wait till someone addresses the problem :-(
I totally agree with @kimimaru4000, I encounter this issue practically every day (I work with data science and many folders are created and updated regularly, so the list view with tree arrows is an essential tool for quick navigation). When the tree arrows are not updated when some folder is not empty anymore, you have to refresh the whole tree which is re-displayed with all collapsed folders and so you have to manually re-expand the previous folders remembering the previous situation, it's a bit annoying.
This issue is still present in Nemo 6.4.5 shipped with Linux Mint 22.2, is there news related to this?
A possible (but partial) solution could be that the View --> Reload (or F5 key) command, after updating the arrows of non-empty folders, resume the current structure expanding again the already expanded folders, so the final effect is that arrows are coherent and you do not have to manually reopen the previously opened ones (see #3198).
I've put together #3743 to fix the original issue described by OP, i.e. nemo is aware that a previously empty folder now has items in it, but does not make an expander appear.
The other related problem is when nemo isn't aware of the change in the folder because it's not monitored, neither in this window or in another. I recognize that the path forward is not necessarily clear. Some ideas from what I've gathered:
This intially 'feels right', and I've often wanted to perform a refresh for a folder deep in the hierarchy.
Especially useful with remote folders which are not monitored whatsoever.
But I've also found myself using F5 as a way to collapse all expanded folders, so...
Refresh does not collapse the expanded folder, but there is a manual way to either:
3.1. Refresh while collapsing expanded folders, e.g. Ctrl+F5, a menu item, or double F5 in quick succession.
3.2 Collapse all expanded folders (without refresh)
Monitor the directory's children.
This has performance implications as mentioned above.
Would only monitor folders that have been loaded/expanded (dummy entry removed), so would scale linearly with the number of folders that the user expands, but might still be prohibitive and/or bad design.
..?
Assuming there is a known direction I could try to contribute towards it (though my nemo codebase knowledge is limited, so can't promise I'll succeed). We should probably track all this in a new issue.
Activity
Jeremy7701 commentedon Oct 17, 2020
The demonstration is in list view; not icon view (as specified in the problem description).
I tried to reproduce the problem in both icon and list view but couldn't reproduce the problem.
kimimaru4000 commentedon Oct 17, 2020
The problem actually was in list view; sorry about that! Maybe this is related to a certain setting. Is there a way to export Nemo settings?
fredcw commentedon Nov 16, 2020
Yes, I noticed this as well. In list view the folder should have a little arrow next to it that you can use to expand the contents if the folder is not empty. When you drag something into an empty folder, no arrow appears. But it will appear if you reload the view (Ctrl-R). It's hardly the worst bug ever but probably worth pointing it out nonetheless.
gkatev commentedon Nov 8, 2021
I've also come here to report this problem! I see the "need info" label, can I help provide information?
The video accurately describes my experience.
All this in list view.
kimimaru4000 commentedon Nov 22, 2021
@icarter09 What extra information is needed to proceed with this issue?
mtwebster commentedon Nov 22, 2021
No extra info is needed. We're aware of this issue, but it's not trivial to fix. I'm considering reverting back to always showing the arrow, whether empty or not.
kimimaru4000 commentedon Nov 24, 2021
Thanks for the update @mtwebster. Do you mind sharing some technical information on why it's not trivial? To my understanding, when a file is moved into a folder successfully, the folder can never be empty, and I'm wondering what could be the underlying problem displaying an arrow in this case.
gaellafond commentedon Jan 5, 2022
This bug is very irritating when manipulating large projects. If I have a set of folder opened multiple layers deep, when I refresh, it collapses the whole tree structure and I have to reopen all the folders, remembering which ones were opened. Always showing the arrow would be a good solution for me.
1 remaining item
fredcw commentedon Jan 5, 2022
I think this is a fairly insignificant bug as you would know anyway that the directory isn't empty if the just moved stuff there. I find the way it currently works is far better than always showing the arrow as that provides far less information and you'd always be trying to expand folders only to find them empty which I think is far more irritating and probably so to far more people.
gkatev commentedon Jan 5, 2022
@fredcw I think the more important problem is (for me at least it is) that you can't tree-expand the folder after moving something into it. Indeed I agree, I am not too fond of having the arrow always showing either.
Jeremy7701 commentedon Jan 5, 2022
If you never showed an arrow, wouldn't that cover the case of empty/non-empty folders?
gaellafond commentedon Jan 6, 2022
@gkatev I agree, keeping the folder structure expanded after refresh would be a good solution.
@fredcw The issue is not about knowing if the folder is empty but rather viewing the files in it. You can't see the files if you can't expand the folder structure. This is a real pain when the folder structure is generated. Every time I trigger a re-generation, I have to refresh the folder. If my objective is to compare the generated files against previous generations, I will have to refresh and re-expand the folder structure of the previous generations after every single attempt. NOTE: The generated folder structure is often really deep, like 10 folders deep. If the arrow was always showing, I would not need to refresh and would not need to re-expand the folder structure of the previous generations. That might seems like a very isolate case, but I'm facing this issue several times a week.
@Jeremy7701 Never showing the arrow would break the tree view feature in list view. You would not be able to expand a folder in list view.
wahmit commentedon Feb 22, 2022
I have the same irritation. Keeping the folder structure expanded after refresh would be my preference. If that is difficult then displaying the arrows on all folders would be reasonable compromise; including the size column informs the user if the folder is empty.
kimimaru4000 commentedon Feb 22, 2022
I'd still like to understand the technical issues regarding this bug. Is it not possible to refresh just a single folder and/or keep the tree view intact on refresh?
I'm wondering why it'd be required to settle for anything less than the expected behavior from users. Other operating systems do not have this issue. @mtwebster would you please provide us with more details?
mtwebster commentedon Feb 22, 2022
Only the active folder gets monitored for changes.
..and so on..
Originally in nemo, all items had an arrow, empty or otherwise. When you clicked the arrow, it would be updated to say 'empty' or would briefly say 'loading' before displaying the folder's children.
Adding monitors to the current directory's children could end up having huge performance/memory implications, plus issues with mounted remote folders (which might not be detected).
I've considered, and talked about going back to that old behavior - always arrows, because at least it would be consistent. To be honest at the time I didn't realize the potential issues here myself or I wouldn't have changed this to begin with.
ps. There's a bug fix for crashes when expanding out-of-date folders that hasn't made it live yet.
kimimaru4000 commentedon Mar 7, 2022
@mtwebster Thanks a lot for explaining the technical challenges! That provides a lot of valuable insight into this issue.
I also feel that keeping the arrows all the time is a better solution for now due to its consistency as you mentioned.
BNIslander commentedon May 29, 2022
I have a quick "workaround" that may be acceptable for some:
In this way the tree structure is not collapsed as would be the case with a "refresh" operation.
lv2eof commentedon Dec 15, 2022
The @BNIslander "workaround" is a bit tricky but it works.
I'll use it till someone fix the bug another way because it also annoys me a lot.
gaellafond commentedon Dec 16, 2022
I totally agree with you.
I have a edge case where I can't move the folder as suggested. The folder is auto-generated by an app I'm developing. The creation of all the files in the folder take about 10 minutes. If I move the folder half way through, the app will crash since its output folder will cease to exists. I need to see the files as they are getting generated to know if it's progressing well and to know when something goes wrong.
The only workaround that works for me is pressing F5, but that's just another annoyance. The generated folder tree structure is about 10 folder deep (the app generates a LOT of files). Pressing F5 close the whole tree structure and I have to navigate again to the folder I was looking at. That gives me headaches...
Just to add some context, the app I'm developing is generating videos from raw NetCDF data files. First step is to generate the video frames (images). Then it combines the frames to create a video. The raw data file contains a multi-dimensional array of data (longitude, latitude, depth, time, hundreds of variable). The large tree structure is necessary to separate the video frames by depth, time range and variables.
This is obviously an edge case, but that issue also annoys me every day, whatever I'm doing. Except the F5 trick works for me most of the time. It's just in that edge case where there is no acceptable workaround.
lv2eof commentedon Dec 16, 2022
@gaellafond
Yes, your case it's a bit on the edge.
Nevertheless I think that as it is now, the Nemo behaviour is incorrect.
The optimum would be no arrow when the forder is empty and a arrow when something enters the folder.
Anyway I agree that this solution can carry some development issues.
So any of the other proposed solutions would be better than the one we have now.
But we have to wait till someone addresses the problem :-(
gbartoli-zcs commentedon Feb 21, 2025
I totally agree with @kimimaru4000, I encounter this issue practically every day (I work with data science and many folders are created and updated regularly, so the list view with tree arrows is an essential tool for quick navigation). When the tree arrows are not updated when some folder is not empty anymore, you have to refresh the whole tree which is re-displayed with all collapsed folders and so you have to manually re-expand the previous folders remembering the previous situation, it's a bit annoying.
Also related to #3198.
gbartoli-zcs commentedon Nov 27, 2025
This issue is still present in Nemo 6.4.5 shipped with Linux Mint 22.2, is there news related to this?
A possible (but partial) solution could be that the
View --> Reload(or F5 key) command, after updating the arrows of non-empty folders, resume the current structure expanding again the already expanded folders, so the final effect is that arrows are coherent and you do not have to manually reopen the previously opened ones (see #3198).gkatev commentedon Apr 2, 2026
I've put together #3743 to fix the original issue described by OP, i.e. nemo is aware that a previously empty folder now has items in it, but does not make an expander appear.
The other related problem is when nemo isn't aware of the change in the folder because it's not monitored, neither in this window or in another. I recognize that the path forward is not necessarily clear. Some ideas from what I've gathered:
3.1. Refresh while collapsing expanded folders, e.g. Ctrl+F5, a menu item, or double F5 in quick succession.
3.2 Collapse all expanded folders (without refresh)
Assuming there is a known direction I could try to contribute towards it (though my nemo codebase knowledge is limited, so can't promise I'll succeed). We should probably track all this in a new issue.