Timeline for How do I remove unsupported characters from a filename on Windows
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 29, 2023 at 10:27 | audit | First questions | |||
| Jul 29, 2023 at 10:28 | |||||
| Jul 26, 2023 at 13:15 | audit | First questions | |||
| Jul 26, 2023 at 13:15 | |||||
| Jul 26, 2023 at 4:40 | audit | First questions | |||
| Jul 26, 2023 at 4:40 | |||||
| Jul 24, 2023 at 1:33 | answer | added | Atario | timeline score: 2 | |
| Jul 24, 2023 at 1:15 | comment | added | MrWhite |
@oxou Actually, the Wikipedia article does clarify that that limitation is regarding the "Win32 namespace". The (NTFS) "POSIX namespace", on the other hand, has no such restriction (except for / and NUL). It would seem that the Linux NTFS driver(s) (The Linux NTFS filesystem driver and NTFS3) have mount options to effectively set the "namespace" used and restrict filenames to those supported under Windows.
|
|
| Jul 24, 2023 at 1:15 | comment | added | MrWhite | @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"!? | |
| Jul 23, 2023 at 16:19 | comment | added | Ben |
Filenames are part of the user interface: So files should be named in a way which makes them easy for users to use. ... ... For example, you can name a file '; rm -rf $HOME' - but this is a very bad idea.
|
|
| Jul 23, 2023 at 11:28 | comment | added | Hastur |
I suppose you should try to manage those files via fileID, in a similar way you should manage via inode under other FS. See fsutil file [queryfileid] <filename>
|
|
| Jul 22, 2023 at 18:14 | audit | First questions | |||
| Jul 23, 2023 at 5:14 | |||||
| Jul 21, 2023 at 20:37 | answer | added | iBug | timeline score: 16 | |
| Jul 21, 2023 at 16:01 | comment | added | user1820994 | @LPChip Interesting, I did not think about that. Thanks again for pointing it out. | |
| Jul 21, 2023 at 16:00 | comment | added | LPChip | @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. | |
| Jul 21, 2023 at 15:59 | comment | added | user1820994 |
@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.
|
|
| Jul 21, 2023 at 15:59 | comment | added | LPChip | @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. | |
| Jul 21, 2023 at 15:18 | comment | added | MrWhite | "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? | |
| Jul 21, 2023 at 12:34 | history | became hot network question | |||
| Jul 21, 2023 at 8:26 | vote | accept | CommunityBot | ||
| Jul 21, 2023 at 6:38 | answer | added | LPChip | timeline score: 40 | |
| S Jul 21, 2023 at 4:33 | review | First questions | |||
| Jul 21, 2023 at 5:32 | |||||
| S Jul 21, 2023 at 4:33 | history | asked | user1820994 | CC BY-SA 4.0 |