Coudn’t delete a folder because of 0x80004005 error

Problem:
A couple of day’s back i couldn’t start my Seafile installation anymore. Although i’ve used Seafile for a while, i just couldn’t really get it working optimal. 

After an export of all my data to an export directory and installing a new VM in Proxmox and installing Nextcloud in it i started transferring all the data to my PC using SSHFS. Also installed the Nextcloud client on my pc and copied the data from SSHFS to a Nextcloud directory, so the data would also be transferred to my Nextcloud server.

During the migration to the Nextcloud server the Nextcloud client gave a couple of errors that directories and files ended with a dot (.). The files were easily changed, The directories were an other issue. In File Explorer it just couldn’t rename the file, because it said it couldn’t find it, although i could select it and press F2 (rename). Requesting the security properties it even gave the following error:
“The requested security information is either unavailable or can’t be displayed“
The solution would be running checkdisk on the disk. I just couldn’t think of why it would be a disk issue. It’s was still possible, but it just wasn’t something i really thought that was the issue.

I read that when transferring from a Linux filesystem, sometimes Windows has no issues with creating the folder, but can’t read it somehow.

Solution:

how to fix it, is a little bit “old school hardcore” command line, back to the old 8.3 file notation. Start a commandline in administrator mode, by clicking the start button and typing cmd. Before clicking enter click with the right mouse button on it. In the menu select “Run as administrator”. You probably get a new box to confirm if you want to run in as administrator, confirm this.

Now go to the directory with the offending directory. Now type “dir /x” and press enter. Then you will get a list of files and directories (directories are the old names of folders) in this directory. Scroll back to the offending directory:

As you can see the directory has the name in the old 8.3 standard of PD9A2E~1. Copy that name and scroll back down.
Execute the following command:
“ren PD9A2E~1 PD“
ren is the command for rename, PD9A2E~1 is the 8.3 name of the directory and PD is the new name. (Replace the PD9A2E~1 to your directory name and PD to your new directory name.)

Execute “dir /x” again:

As you can see the 8.3 style name is removed (The name is now withing the 8.3 format). Now you can do what you want in the file explorer again.

Update:
You can do the following:
“ren PD9A2E~1 THIS_IS_A_VERY_IMPORTAND_OBJECT”. 
So renaming it to an 8.3 object isn’t the solution to the problem. The dot after the object is the problem.

 

After thought

The strange ting is the dot on the end. If i create a directory with the dot and nothing after it using file explorer, the dot is removed and the directory is created. Even on the command line the dot is removed and the directory is created (test12.3. is created as test12.3), so i think during the copy command (used robocopy) the dot after it, isn’t a real dot, but a special character. After the directory (or file) is created, windows handles it as a dot, but the character is something else. When windows tries to do something with the object it sees P.D. and thinks it says PdotDdot, and requests the info, but the files systems doesn’t see the object because in his administration (the filesystem has his own “administration”) can’t find the directory because in the administration the object is name PD9A2E~1.