Can't rename directories

Support & Help Requests
1

For a few days now (I don't know if it was after an update or something), when I create a new directory through the graphical interface and the menu in the Documents directory, it creates an "untitled folder" directory.
The problem is that when I try to rename that directory through the menu, it doesn't do anything. I can't do it.
Through the terminal. If I try to rename it with the "mv" command, I get the following error message.

mv: cannot perform `stat' on 'untitled folder': No such file or directory

And therefore I can't rename the directory created graphically through the command line either.

As far as I've noticed, it only happens in the Documents directory. There's no problem with the rest.

Yes, I can create a directory in Documents using the command line and the "mkdir" command. In this case I have no problems naming it as I want or renaming the directory either with "mv" on the command line or graphically using the menu.

I have checked the permissions of the Documents directory and have not found anything abnormal.

Has this happened to anyone else? Can anyone give me any ideas on what I can look at to fix it? It's annoying to have to create directories with the command line before using them when you're working with the graphical interface.

1 Like
2

Welcome, @majere to the community!

3

You've provided little for us to provide meaningful help with.

Basic details would include your release (this provides details as to your software stack, versions etc, even letting us know what updates have occurred in the last few days as those are release specific), you mention update but have provided no clues there (eg. I update multiple times per day, but you may update daily, every 2-3 days, weekly etc which lets us consider what may have updated in that time given you do mention updates).

Your problem would also benefit with details of your file-system (ie. default ext4? or something else?), and clear example of what you're seeing (ie. what you create etc).

Have you made any changes of late? the most critical ones will be changes made in the final session before this problem occurred (this can include changes to keyboard, language & more). Have you jumped to terminal & explored what is actually created, contrasting that with your intent? and considered any changes made in the session(s) prior to this problem appearing? Did you explore what was updated? (ie. apt logs in /var/log/apt/history.log for example)

For us to be helpful, we need some specifics. (I assume this is a local system, not accessed remotely etc.. as that detail should be provided too)

1 Like
4

Documents dir has permissions 755 and owned by $USER

Using caja
create new folder in Documents, untitled folder
highlight untitled folder, press F2, change name to foo
folder's name is now foo

1 Like
5

When you click "Create Folder", without doing anything else,

  • does Caja show the directory with the name in an edit box ? or

  • is it simply highlighting the entire line for that directory like any other single-click on a file for selection in Caja ?

If the first, just type the name (with no further mouse action) then hit enter.

If the second, it sounds like something is "stuck". I don't have any ideas as to what would be causing that. :frowning:

6

The file system is the standard ext4.
The system is a 22.04 LTS desktop.
When I refer to updates, I mean the various update commands that I frequently do.

$ sudo apt update
$ sudo apt upgrade
$ sudo apt dist-upgrade
$ sudo aptitude update

I find the log issue a bit absurd, since this could have happened yesterday, which is when I realized it, or a year and a half ago and I didn't notice it until yesterday.

Normally I do things in directories and files on the desktop and then I organize them on the desktop itself and I graphically copy said files and directories into the Documents Directory to save them. Doing that I have had no problems.

The problem has been when I have tried to create a new directory directly in the Documents directory graphically (in a box). Either through the key combination CTRL+SHIFT+N, through the menu ->File->Create folder. Or from the quick drop-down menu with the left mouse button "create folder". A directory named "untitled folder" is created. The normal thing up to now and in other directories where I create folders is to be able to modify said name. If I don't do it and keep it as "untitled folder" the normal thing is to be able to rename it. But that is the problem that does not allow me to rename it either graphically in the box. Nor through the command line with the command "mv". Which gives the following error message that seems relevant to me.

mv: cannot run `stat' on 'untitled folder': No such file or directory

I don't understand the meaning of "stat" or what is "stat". A program? A process?
The directory exists. I can create files and directories inside it and I can delete it without problem. What I can't do is give it a name when I create it or rename it afterwards. Neither graphically, nor through the terminal.
As a curious fact after doing more tests. If I create it, I don't delete it and keep the "untitled folder" directory and create another directory, it creates "untitled folder 2" but this new folder does give me the option to give it a name or rename it later. All the folders I create if I keep the "untitled folder" directory work normally. It gives me the option to give them a name when I create them and rename them later. As long as there is a directory called "untitled folder". Which is annoying.
And I want to know if someone else has had something similar happen to them. Why can it happen? How to solve it. Where is the origin of the problem (in caja? in MATE? in gtk? in some . lib).

My options for now to try to solve it, could be.

Reinstall caja. Let's see if it solves it.
Leave the "untitled folder" directory and hide it.
And wait to see if when I update to 24.04 it is corrected.

7

Yes, those are the permissions I have. But just in case I have been changing them and testing with other permissions on the directory.

I have also tried using the root user.

In theory it should be as you say. So far it is how I have done it and how I do it with other directories.

But this time it does not work.

It does not give you the option to assign a name. Instead, the system assigns it directly. And it does not give you the option to rename it.
In Caja it does nothing when you press F2 to rename it or anything when you click on it with the pointer and the quick rename menu.
In the command line with "mv" it gives an error message that the directory does not exist.

However, thanks. You have given me the clue that the problem may be in Caja.

8

Yeah, it looks like something is stuck. I'll see if I can figure out what it is. It's very strange.

9

Point [a] - So, just to confirm, you are saying that when you click on "create a directory", the "untitled folder" shows up without allowing you the opportunity to modify the filename ?

Point [b] - But it only does that for the first such new folder, not with any subsequent request, as long as that first folder is present ?

Point [c] - And, that only applies to the GUI-based mechanisms, not with command-level by the same user in the same directory?

Question 1:
If you use the command line

mkdir "untitled folder"

does the system behave differently than when you do

mkdir "testDir"

???

Question 2:
If you click on the "Refresh" button, then try to rename, does Caja behave differently?

For myself:
Mode 1 [CTL+SHIFT+N]: no issue
Mode 2 [Menu -> File -> Create Folder]: no issue
Mode 3 [right click-> Create Folder]: no issue

Version: Caja 1.26.0
Ubuntu 22.04.4 LTS
Linux 5.15.0-119-generic #129-Ubuntu SMP Fri Aug 2 19:25:20

Side Issue - 'umask'
Also, I haven't used umask in ages, for lack of need, but I went looking for it now ... and it is NOT part of the basic OS !!! How very strange !!! I was going to ask you to verify your umask value at both

  • mate-terminal prompt (opened from Brisk), and
  • mate-terminal prompt (opened from Caja showing parent directory -> File -> Open in terminal )

I was curious to know whether those two had different values, which the defaults appear to be

  • 002 for directories, and
  • 113 for regular files
10

stat is a program that provides details about the directory, when it was created, accessed, modified, etc.

1 Like
11

Not sure which version gives you that behaviour, but my version gives me the following (note: No caps!!!!):

untitled folder

P.S. I'm also very familiar with stat ... use it all the time! :slight_smile:

2 Likes
12

my error, it makes "untitled folder" I will fix the post.

1 Like
13

Indeed.
To points 1 and 2.
In point 3 in part.
If I try to rename that first "untitled folder" through the command line with "mv" it doesn't let me either. That's when I get the error message.
To answer question 1:
If I create a folder from the command line with "mkdir" there is no problem at all. It is called by whatever name, "untitled folder" or "testDir". There is no problem in the command line at first.
Question 2:
I haven't tried updating because I've already found a solution.
But I will try it when it happens to me again in another directory, because I have found another directory where the same thing has happened to me.
The solution I have found is to move the entire directory location and then move it back to its original location.
Let me explain. I copied the entire Documents directory to the Desktop and then moved it back to its original location, my home folder.
When I tried again after doing this, the problem was gone. The new directory was created normally and I could assign it the desired name and rename it without any problem.

However, I still have a question about why this can happen.

My version of Caja and Ubuntu are the same. My kernel version is 6.8.0-40-generic

I'm not used to using umask, I've looked at the permissions after creating the directories with "ls -l" and through the properties tab of the directories. And I haven't seen anything abnormal in them.
However, I will study that command and the Brisk command, which I don't know what it is but I found it interesting to learn even though it seems to be obsolete.

Thanks for your interest and concern. You never know. It could happen to you tomorrow when you upgrade to 6.8.0-40-generic.
Then we'll know that the update was the cause and how to fix it. I don't think that was the cause though.

Lately I've been installing wifi controller drivers and from what I've read they do unexpectedly weird things, affecting unexpected things. It could be. I'll keep testing and investigating.
But at least I've found a temporary solution even if I don't know what the cause is.

1 Like
14

Thanks for the info.
I will study the info, help and man. of the stat program.
And I will try it in the next directory that gives me the same error if that is the case.
It is always good to know.

15

Sorry.
I'm not used to participating in forums so I don't know if I'll be able to do it, but I'll try.
However, the problem I had was renaming or assigning a name or renaming the directory at first when I detected it.
Therefore, I don't think the title is wrong at all.
I also go into a little more detail in the exposition of what the problem is.
However, I'll try to make the title more specific if I find out how to do it.

16

Gracias por la bienvenida.
Que como he estado liado a ver si solucionaba el problema, como he habia afectado y que lo causaba se me ha pasado tu menaje.
Y me parece desconsiderado el no responder a un mensaje de bienvenida.

Perdona que te responda en español si eres anglo-parlante.
Pero como he visto por tu nick que es una palabra en español y que el traductor no la traducia, he interpretado que eres hispanohablante. Y esta noche estoy cansado de usar el traductor de google.

1 Like
17

Based on what you are saying, something is happening

  • either with the properties/privileges of the directory itself, or
  • maybe a hidden file that was not there before the attempt to create the folder.

About your "process fix",

  • do you copy the directory using mouse clicks (same or different disk) ... delete the original folder ... then copy back, or
  • do you mouse drag the directory to another location on the same disk, then drag it back to where it was (again on the same disk).
2 Likes
18

Yes, it could be, but the properties, permissions and privileges of the directory when I did an "ls -la" on it did not give me anything abnormal. And when I used the root of the system they should not affect. The same for the hidden files. The "-a" option of "ls" did not show me any hidden files or directories beyond "." and ".."

Specifically because I think I explained it wrong before. I do not copy. I cut and paste the directory in another location on the same HDD. When cutting, the directory is deleted at the source. When copying, it is not. So I cut.
Then I do the reverse process to put the directory back in its original location.

In this specific case, I cut the Documents directory and pasted it on the Desktop.
And then I cut the Documents directory and pasted it in my user's personal directory. Which is its original location.

In this way, for now, it seems that the problem has been solved and I can now create directories graphically, allowing me to name and rename them.
I know that it is not entirely correct and that there is some error, because even when I create a directory graphically, it appears dark in the directories where this problem has occurred, which does not happen in the directories where the problem has not occurred. But at least the system is functional now.
Hopefully, when I update the system to 24.04 at the end of the month, the problem will be corrected. However, I will continue studying it. When it happens again, I will use the "stat" command to see if I can get more information. At least this has helped me to learn about this command, which I was completely unaware of.

1 Like
19

So, if I understand correctly, the method (that repairs the offending properties) is to perform the "cut+paste" (to new location, then back to original location) to resolve the issue.

You say that you have to do this at least once for every directory where you want to use Caja to create a new folder ?

  • Is that required (only?) [a] for all folders under your HOME, or
  • is that required (only?) [b] for any folder on the root disk drive, or
  • is that required (only ?) [c] for any folder on any non-root internal disk drive, or
  • is that required (only ?) [d] for any folder on any non-root internal SSD, or
  • is that required (only ?) [e] for any folder on any USB disk drive, or
  • is that required (only ?) [f] for any USB SSD (RAM stick)?

If you open Caja as administrator, do you encounter the same issue for the same operation(s) ?

Are you saying that Caja window where the problem occurs looks like the window "lost focus" including the title box losing its "highlight" ?

1 Like
20

Well, it seems that I have solved it and I confirm the solution.
I still don't know why it started, but it seems that I had almost all the files and directories in the Documents directory in the same situation. It's not that it didn't allow me to rename the new directories that I created in that directory. It's that I couldn't rename most of them.
Curiously, this didn't happen with the files and directories inside the directories of the Documents directory.
Once I did the process of copying the entire Documents folder to the desktop, the issue of allowing me to give a name or rename the newly created directory was solved. Even so, the rest didn't.
This time it did allow me to rename them without any problem with the command line and the "mv" command, but not through the graphical interface.

Looking at the results of the "stat" command, I haven't found anything abnormal.
Even if I changed the permissions of the directories or files either through the graphical interface or by using the "chmod" command, it still wouldn't let me rename the files with the graphical interface.
I confirmed that the permissions had changed correctly with both "ls -l" and "stat".

So in the end the procedure I followed and now I notice a normal functioning in the directory is:

1.-Create a directory called "intercambio" on the Desktop.
2.-Do a "chmod 755 *" in the Documents directory through the command line.
3.-Cut all the internal content of the "Documents" directory and paste it into the "intercambio" directory.
When I tried to rename a file with the graphical interface in the "intercambio" directory, the problem persisted. That is, it still didn't allow me to rename it with the graphical interface.
4.- Cut all the internal content of the "interchange" directory and paste it into the "Documents" directory
When I tested a couple of files and directories once they had been copied back into their original "Documents" directory, I was now allowed to rename them in the graphical interface. When I tried to create a new directory in the "Documents" directory, I was now allowed to give it a name and/or rename it later in the normal way.

So I think I have now solved the problem. And I can confirm that this method works correctly.

I still don't know why or when it happened, and I don't think I'll ever find out. Nor if there may be more affected directories. But the fact is that the procedure works correctly.

I want to understand that it is very likely that something went wrong in the "box". Because the main problem was in the graphical interface and through the command line they were not given. The permissions were correct and the change of them was carried out correctly.

When I cut the "Documents" directory and pasted it directly into the "Desktop", and then did the reverse process. I solved the problem of not being able to create directories graphically and give them a name or rename them later. But I didn't solve the same problem that occurred with the rest of the files and directories within the "Documents" directory.
When I created a new directory with the graphical interface, I was now allowed to rename it, but it had strange graphical effects, the behavior was not completely normal, the renaming request appeared in a strange place and the folder was duplicated and darkened until I assigned the name to it. It was not the usual behavior. Something still did not work normally.
Through the procedure written above I confirm that for now everything works normally. And if I have any other directory that has the same problem, I can now solve it with this quick procedure.

I suppose it is something strange and there are no more affected, but just in case, I leave it written here. In case it helps anyone.

My thanks to everyone for their interest, help, and knowledge. Although I leave with the bittersweet feeling of not knowing the causes. The experience has helped me learn some new things and I take with me the satisfaction of having (I think) solved the problem.

3 Likes