1

Using CentOS 6.5, there's a file in my directory whose name is 161 characters. This directory is shared between the host VM (Windows) and Guest VM (Vagrant).

I can't access it with ls:

> ls long...file
ls: cannot access : No such file or directory

I'm speculating that this long file name may be the reason for my build clean-up process may be failing.

Also, when I ls -lrot the directory containing the file, I see a bunch of question marks, ???.

What options do I have to clean up this file?

Kevin Meredith
  • 395
  • Is the file on a volume shared by a Windows system? – Daniel Beck Apr 16 '14 at 21:15
  • yes it is. I tried both the basic synched_folders offered by vagrant, as well as smb (http://docs.vagrantup.com/v2/synced-folders/smb.html). I'm experiencing the above problem on both setups. – Kevin Meredith Apr 16 '14 at 21:17
  • 2
    There you go. Don't store long paths (total length from Windows POV -- i.e. C:\Users\Username\Documents\blablabla...) longer than about 260 chars) on a volume mounted by Windows. Just doesn't work. There are some workaround but you'll save youself a lot of headache by just not doing this. – Daniel Beck Apr 16 '14 at 21:25
  • Ah, so it doesn't matter where it's mounted on the guest VM: /vagrant or /u01/a/b/c/. The problem is that the Windows path length is too long? Also, - my Windows Path Length + Long File = ~260, which is right around the number you listed as being a problem – Kevin Meredith Apr 17 '14 at 13:29
  • Exactly. If you try creating those paths on Windows locally, you're going to fail as well, no CentOS, Vagrant, etc. involved. I'm closing this as a duplicate for now. No reason to keep a copy around just because the circumstances are such that the question doesn't even mention the most important part. If you discover it's actually unrelated to the Windows issue, however unlikely, please post a comment to let me know. – Daniel Beck Apr 17 '14 at 18:30

1 Answers1

4

The pretty much ultimate solution when it comes to files that can't be deleted by normal means:

ls -il

The first column will show the inode number of the files.

find . -inum [inode-number] -exec rm -i {} \;

This will delete the file with the specified inode-number after verification.

Squeezy
  • 9,392
  • This answer deserves a favorite ;) – ek9 Apr 16 '14 at 21:30
  • The problem with this answer is, that it can resolve a ton of different questions, that themselves are totally unrelated except for the answer. :( – Squeezy Apr 16 '14 at 21:35