I'm running Ubuntu 22.04 and would like to create a file having the pipe character ("|") in its filename. (Necessary to run some legacy code.) Specifically, how do I identify and correct the pitfalls that are preventing me from doing so on certain drives of a Linux/Windows11 dual boot system?

I think dual-boot is an issue because I can successfully create such a file in some directories on my machine, but not those on disk drives that Windows can read (see below). Someone else originally installed the operating systems, so I don't know what choices they made that could affect this question.

Here is what I've tried. The attempt below works, so we know there's no fundamental objection from Linux:

xname@blackbox:~$ cd ~
xname@blackbox:~$ touch "|"
xname@blackbox:~$ ls -l "|"
-rw-rw-r-- 1 xname xname 0 Feb  9 10:17 '|'

Likewise, I can successfully touch the file if I'm in the /media directory or in the /media/xname directory.

xname@blackbox:/media/xname$ cd /media
xname@blackbox:/media$ sudo touch "|"
xname@blackbox:/media$ cd /media/xname
xname@blackbox:/media/xname$ sudo touch "|"
xname@blackbox:/media/xname$ ls -l
total 12
-rw-rw-r-- 1 xname xname    0 Feb  9 11:35 '|'
drwxrwxrwx 1 xname xname 8192 Feb  8 17:25  cdisk
drwxrwxrwx 1 xname xname 4096 Feb  9 11:30  ddisk

You can see the permissions on ddisk above. Its parent directory had an ACL when I originally got the machine, but I removed it using setfacl -b ddisk and then re-booted.

The touch attempt fails inside ddisk (and cdisk):

xname@blackbox:/media/xname$ cd /media/xname/ddisk
xname@blackbox:/media/xname/ddisk$ touch "this_works_fine"
xname@blackbox:/media/xname/ddisk$ touch "|"
touch: setting times of '|': No such file or directory
xname@blackbox:/media/xname/ddisk$ sudo touch "|"
touch: setting times of '|': No such file or directory

Perhaps part of the output of the findmnt command will be helpful:

TARGET                                   SOURCE           FSTYPE  OPTIONS
/                                        /dev/nvme0n1p5   ext4    rw,relatime,er
├─/media/xname/ddisk                     /dev/nvme1n1p2   fuseblk rw,nosuid,node
└─/media/xname/cdisk                     /dev/nvme0n1p3   fuseblk rw,nosuid,node

And here is the output of mount | grep media

/dev/nvme0n1p3 on /media/xname/cdisk type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
/dev/nvme1n1p2 on /media/xname/ddisk type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

Another puzzling thing about this machine that may be relevant: When I sign in, I'm asked for a password for an account that is not xname. I don't know where xname came from.

Thanks for your help.

  • @roaima: Done! Thanks. Commented Feb 9, 2023 at 21:34
  • Mmm fuseblk isn't telling me anything helpful. I can create filenames containing | on ext4 and NTFS filesystems. I wonder if yours are vFAT or xFAT? Commented Feb 9, 2023 at 21:41
  • @roaima: I looked but could not get my arms around any way to tell if vFAT or xFAT is used by those disks. It's a reasonable bet, though, as the machine started as Windows and then had Linux installed second. Commented Feb 9, 2023 at 22:24
  • I don't know of any other filesystem that prevents the use of |. (Windows OS does, but its filesystems do not.) Commented Feb 9, 2023 at 22:33

1 Answer 1


It shouldn't really matter which DOS/Windows specific file-system you use; they all forbid the following characters (per this MS page) ....

Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following:

The following reserved characters:

  • < less than
  • > (greater than)
  • : (colon)
  • " (double quote)
  • / (forward slash)
  • \ (backslash)
  • | (vertical pipe or bar)
  • ? (question mark)
  • * (asterisk)

I doubt that there's an abstraction layer that pulls those out irrespective of filesystem, but I'm obviously not an MS Employee and don't know for sure. I guess that all Windows-filesystems implement that limitation and it seems only logical that the linux-implementations of these honour those. I'd imagine that if you e.g. managed to create the file *hey|there on Linux and then booted windows and it were to run a fsck it would get quite upset. ;)

  • 1
    That's not right. The Windows interface (and API) forbids | but the NTFS filesystem does not. I have tested this just yesterday using Cygwin Commented Feb 10, 2023 at 8:10
  • "I doubt that there's an abstraction layer" - it's the Windows API. The section of documentation you quoted is a Naming Convention, not a hard requirement. The topic goes on to explain how to bypass this (otherwise enforced) naming convention for special cases Commented Feb 10, 2023 at 8:12
  • Further checking (again, on NTFS) the only characters from that list I cannot put into a filename are / and \ . Windows Explorer on the other hand, struggles to list or otherwise do anything with files containing any of the listed characters. Commented Feb 10, 2023 at 10:03
  • 1
    This is all very helpful, thanks. It must be true that the filesystem on the offending disks is vFAT or xFAT and so therefore it is hopeless to seek a workaround. There appears to be no other choice but to reformat ddisk. This will probably mean that Windows 11 won't be able afterwards to see the disk, but cdisk is still available for Windows-Linux file exchange, and so the price of reformatting is reasonable to pay. Commented Feb 10, 2023 at 18:03
  • 1
    @IronPillow - I think that's a very wise decision.
    – tink
    Commented Feb 10, 2023 at 18:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .