Apologies in advance as I am sure this has been asked before, but I have been unable to locate any previous posts due to not knowing this behavior's name.

I have been noticing that many of my directories have been renamed to so something like the following when I do `ls` in the command line: 

AWSVI4~U/
AWT44A~A/
AWTG9Q~4/
AWVBVQ~S/
AWWPW5~4/
AX1FG1~5/
AX4ROW~G/
AX6IG2~B/
AX9N8N~T/
AXEAWT~X/
AXGKR7~X/
AXTZHE~6/
AXX89X~Q/
AXXQ3N~1/
AXY21M~3/
AXYEMA~B/
AY6IL5~G/
AY9CO0~Y/
AYDVWF~W/
AYGYF6~S/
AYHK2F~4/
AYICEK~E/
AYKN8G~5/
AYP24I~B/
AYVCSJ~D/
AYXEJE~4/
AYZZUR~4/
AZ7DOQ~D/
AZ8GE5~V/
AZB27W~Y/

My array is using XFS. It doesn't seem like corruption because the files within these directories are still accessible and the renaming is so uniform. 

 

So a few questions:
- What system or feature is causing this (so I can read more about it)?

- What causes some directories to be renamed and other to not be renamed?

- How can I disable this renaming and restore my directories to their original names?

 

Thanks in advance!

Edited August 19, 20241 yr by Nexal

Never seen that before!

 

it look like the sort of names you end up with on Windows when files are moved to a file system that does not support long file names

Hmm. I almost never use windows with this unraid server so I would be surprised if it came from there. 

I asked ChatGPT and it said: 

 

Quote

 

What you're experiencing is likely due to a feature in XFS called "sparse subdirectory names" or "shortening of long directory names". This behavior occurs when there are many files with very similar names that have been renamed.

 

Here's why it happens:

• XFS caching: To improve performance, the XFS file system caches directory entries. When a new file is created or renamed, its name is stored in the cache.
• Directory hash table: The cache uses a hash table to store the directory entries. This hash table has a fixed size (default is 512 bytes), which limits the number of unique directory names that can be stored.
• Name collisions: When you have many files with very similar names, it's possible for them to collide in the hash table. In this case, XFS will automatically shortening the name by removing the common prefix and appending a unique suffix (like ~5 or ~B).
• Renaming issue: This shortening occurs during renaming operations, not during file creation. When you rename a file, its original name is used to look up in the hash table. If there's a collision, XFS will shorten the original name and append a unique suffix.

 

However, when I was trying to learn more about 'sparse subdirectory names' there was practically no additional information which made me think that ChatGPT was likely making the name up. But not sure, to be honest, which is why I thought I'd ask real humans who likely would know a more accurate answer. 

It is possible that these file names were quite long, maybe >80 characters. But I can't see their original directory names to confirm so this is just a guess. When I manually create longer file names they don't get renamed within the observation period. So it's got me stumped. 

 

Edited August 19, 20241 yr by Nexal

Are they in the expected location, did you run a filesystem check lately?

 

@KilrahThey are in the expected location. What do you mean by a filesystem check? Like a parity check or something else?

No, if you've had to check/repair your XFS filesystem since that looks somewhat like what lost files could be named after a check.

I haven't manually started a repair, but is this something unraid does automatically on a periodic basis?

No, so unrelated

Another thing to investigate would be a client machine that has access to the files could be infected with ransomware. I've seen behaviour where the original file was renamed, and an encrypted copy written with the original name. The end result would be the deletion of the randomly named files, but maybe not all the actions are able to happen over a remote share.

Interesting idea. Though the files are still accessible in the renamed folders and I haven't found any location that the original name with encrypted contents. I assume these encrypted files would be located in the same location? 🤔

Did you try opening some of the files to see if they're intact?

Great question! I have clicked through three or four directories and picked a random sample of files from each, and each appeared to be completely intact. 

Edited August 19, 20241 yr by Nexal

I encountered this kind of problem: file/folder names mangled (when copied over SMB) where a file or folder name ends with one or more blank spaces. I removed any blank space at the end of a file/folder name BEFORE copying to preserve the file/folder name. I hope this helps you troubleshoot your problem.

Hmm seems like a possibility as I do use SMB. I’ll do some experiments the next time I am at my computer. Unfortunately, if this is what causes the issue, I am guessing the previous directory names would lost to history. But would be satisfied to at last understand this behavior better so thanks for sharing!
 

Will update tomorrow morning as soon as I’m able on any findings 

Sorry for the delay, work picked up before I had to go out of town. I've finally had a chance to do some experimentation and so far extremely long file names and file names that end in spaces and so far after transferring with SMB neither has yielded the garbage names. Will continue to keep an eye out though for more circumstances where it occurs though.