21

I've used a live boot CD of Linux couple weeks ago and have redirected screenshots to my NTFS drive.
The filenames contain a colon symbol : which is one of the unsupported characters for a filename on the NTFS file system.

Unsupported characters are: \ / : * ? " < > |

I tried to solve this using the regular Command Prompt, PowerShell, some scripting languages, and even Bash on Windows but none worked.

I even tried the \\?\ path trick but it doesn't work either.

The limitation is obviously tied to the NTFS file system, so what's the way to continue from here?

Improve this question
9
  • 7
    "The limitation is obviously tied to the NTFS file system" - is the limitation the "NTFS file system" or "Windows"? Since you were seemingly able to successfully save files with filenames with these "unsupported" characters to the NTFS drive from Linux?
    – MrWhite
    Commented Jul 21, 2023 at 15:18
  • 6
    @MrWhite you and I know this is a limitation of Windows, not the NTFS filesystem. But keep in mind. If OP had known the answer to the question, they would most likely have been able to solve it themselves already and not have the need to ask here. Although they make a false statement, for us troubleshooters, it is a great deal of information because that helps us understanding their thoughtprocess.
    – LPChip
    Commented Jul 21, 2023 at 15:59
  • 3
    @MrWhite If you read the Wikipedia regarding NTFS you'll see on the right side explicitly written Allowed filename characters: ... except /\:*"?<>|. I think what happened is that the driver used on Linux to interface with NTFS did not account for these "limitations", as I believe the driver had raw access to the MFT and had written the filename without first checking the character range.
    – user1820994
    Commented Jul 21, 2023 at 15:59
  • 2
    @oxou as they all say, not everything you read on the internet is true. That statement is inaccurate. It assumes Windows when NTFS is mentioned, but does not think of other systems that don't have this limitation.
    – LPChip
    Commented Jul 21, 2023 at 16:00
  • 2
    @LPChip It was actually a serious question. Whilst instinct might suggest this was a Windows issue, the numerous articles I was seeing all suggested it was a "limitation of the NTFS filesystem"!?
    – MrWhite
    Commented Jul 24, 2023 at 1:15

3 Answers 3

Reset to default
40

Boot back into your linux live cd and correct it from there.

Windows just can't handle this. This needs to be done from linux.

Improve this answer
4
  • 7
    This is actually true. The reason the \\?\ trick didn't work is because : means open alternate stream, so either you write C code against the NT Native API or you boot Linux again and have it fix its own problem.
    – Joshua
    Commented Jul 21, 2023 at 14:35
  • Can't one make a program for the POSIX subsystem of Windows to do the job? Or have the latest versions of Windows gotten rid of this subsystem?
    – Ruslan
    Commented Jul 23, 2023 at 19:39
  • 5
    Up until just recently, the usual Linux driver for handling NTFS was ntfs-3g, which has the mount option "windows_names". Using that option would prevent creating filenames which cause difficulty on Windows.
    – kreemoweet
    Commented Jul 24, 2023 at 3:29
  • @kreemoweet Thanks for bringing this up, I'll keep that in mind when mounting NTFS on Linux.
    – user1820994
    Commented Jul 26, 2023 at 7:28
16

@LPChip's answer is the answer that solves your problem, but I have more details that I think warrants another answer here.

Filesystems are data structures that manage your files on a disk, so normally FS themselves have minimal restrictions on file names - most modern FS (NTFS included) can even technically hold null bytes just like how Python holds strings (length + array of bytes).

That FS supports arbitrary strings does not mean you should. Practical operating systems impose restrictions on file names so that they can present a sensible "path" interface to the upper level, where applications can access files.

This is the reason every OS has some limitations on file names. Notably, Linux and other Unix systems allows all characters except the null byte and the path separator (forward slash) in file names, excluding two reserved names . and .. (current directory & parent directory). Windows, for historic reasons, reserves more characters and more special names (e.g. CON, LPT, COM1 to COM9 etc.) through normal Windows API, but still allows these names via a low-level API as used by WSL1. For example, you can create something like /mnt/c/CON in WSL1 and use it normally, but you can't do anything with it outside WSL environment.

On Linux, fsck programs can rewrite invalid file names if they somehow end up in the filesystem. I suppose chkdsk.exe can do something similar but I have not verified that.

Improve this answer
2
  • 1
    chkdsk.exe can outright delete your stuff, so it can fix the problem that way.
    – Nelson
    Commented Jul 22, 2023 at 17:29
  • When calling NT Native APIs I can place that NUL byte in the filesystem. I cannot however place a forward slash. The documentation is scanty so I can't tell how alternate data streams work definitively.
    – Joshua
    Commented Jul 22, 2023 at 22:24
2

Wikipedia's sidebar claim about the disallowed characters cites a document (not official, it seems). There is a web-page-ified version here.

Digging into it, we see in section 13, "Concept - Filename Namespace", that there are multiple allowable character sets. Windows doesn't play nice with the POSIX one, it seems.

However, the mention of the DOS type (the old "8.3" style) brings to mind Windows' ability to deal with the so-called "short names" if all else fails. You should be able to use a cmd prompt to do dir /x to see the short name corresponding to the file's forbidden "long name". It may be possible to use that "short name" to rename the file to something with fewer problems.

Please let us know how it went!

Improve this answer
2
  • 1
    A good idea and worth a try.
    – Falco
    Commented Jul 24, 2023 at 9:54
  • 1
    This is a good idea that I'll keep in mind if I ever encounter the same problem. Though in this particular case trying dir /x does not return the 8.3 naming scheme even after I've set NtfsDisable8dot3NameCreation to 0 and restarted the PC.
    – user1820994
    Commented Jul 26, 2023 at 7:14

You must log in to answer this question.