17

I can't create folders or files named 'com1', 'com2', ..., 'com9' in my extended hard drive. I'm trying to create a Wine prefix on my other drive where my games are stored, but I get some errors.

enter image description here

Here is a pastebin of the whole output when I run winecfg to a new prefix. https://pastebin.com/SsaAFGdw

I believe it's not a permission issue since I can make directories and files. And, I also tried creating a prefix from my main boot drive, then move it to my extended hard drive, then I get errors when it's now trying to copy files named 'com1', 'com2', ..., 'com9'.

enter image description here

This is how my extended drive partitioned: enter image description here

sudo WINEPREFIX='path' winecfg also does not work, same result.

EDIT: OS: Manjaro KDE Plasma

Output from mount | grep /dev/sdb:

/dev/sdb2 on /run/media/snich/Extended type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
/dev/sdb4 on /run/media/snich/Games type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
/dev/sdb3 on /run/media/snich/Personal type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
snich
  • 179
  • 1
  • 7

2 Answers2

32

Assuming ntfs-3g is used,windows_names is probably set somewhere as an option. Seen man page

OPTIONS

windows_names

This option prevents files, directories and extended attributes to be created with a name not allowed by windows, because

  • it contains some not allowed character,
  • or the last character is a space or a dot,
  • or the name is reserved.

The forbidden characters are the nine characters " * / : < > ? \ | and those whose code is less than 0x20, and the reserved names are CON, PRN, AUX, NUL, COM1..COM9, LPT1..LPT9, with no suffix or followed by a dot.

Existing such files can still be read (and renamed).

Edited response :

I'm currently with debian/Buster and there is a /etc/udisks2/udisks2.conf file containing :

### For the reference, these are the builtin mount options:
# [defaults]
[...]
# ntfs_defaults=uid=$UID,gid=$GID,windows_names
# ntfs_allow=uid=$UID,gid=$GID,umask,dmask,fmask,locale,norecover,ignore_case,windows_names,compression,nocompression,big_writes

So, for debian, and probably most of their derivatives, mounting an NTFS implies using option windows_names. As explained in the same file (a little bit higher), you could try putting your options in a /etc/udisks2/mount_options.conf file. Just edit/create the file, copy those two lines, remove leading hash and remove option windows_names. Do everything as root, and take care of permissions.

Unmount and re-mount.

(Now, I'm not sure all this is a good advise : as Wine will act "à la" MS-Windows, this will not end to be a good thing.) This is just a feeling, not fact, and many others did proved it doesn't hurt.

Enjoy !

user4089
  • 878
  • 6
  • 14
  • 8
    They really didn't like the folder called NUL I created on the file server a decade and a half ago. – Joshua Oct 05 '22 at 17:47
  • 1
    `this will not end to be a good thing...` this isn't true at all. Windows supports names like `con`, `lpt` or `comX`... without any problem. It just forbid them by default for backward compatibility with DOS. You can create files with those names in Windows by [prepending \\?\ to the name](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file) – phuclv Oct 06 '22 at 15:20
  • @phuclv and Joshua are right, I just gave there a bad feeling without any proof. I edited my response. – user4089 Oct 06 '22 at 17:08
  • 2
    @phuclv Just because NTFS (and Windows) supports them doesn't mean applications will. If an application tries to open your file named `COM4` without using UNC form (the `\\?\` prefix), they'll get an error. Most programs don't use UNC paths because they're not really necessary. Since OP is using Wine, the programs they use probably will have issues. – Cole Tobin Oct 06 '22 at 17:38
  • @ColeTobin: Explorer on windows doesn't use `\\?\` so ... – Joshua Oct 06 '22 at 20:35
  • @ColeTobin the (GUI) apps usually open files by full path. Will an attempt to open e.g. `C:\some dir\COM4` result in an access to COM4 port? – Ruslan Oct 07 '22 at 15:42
  • @Ruslan yes. It’s a backwards compatibility thing. Originally, DOS didn’t support directories. Then, when it did, they wanted to make sure programs opening `COM4` (technically a relative path) would still work even if not in the root directory. – Cole Tobin Oct 07 '22 at 22:09
8

WINE is emulating Windows and so must be compatible with it. COM* are reserved words for com (serial) ports under MSDOS and WINDOWS.

Microsoft help

Do not use the following reserved names for the name of a file:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. For more information, see Namespaces.

Rohit Gupta
  • 375
  • 2
  • 3
  • 12
  • 10
    That in itself doesn't explain why it won't work. These reserved names are a (1970s to 1990s) MS-DOS problem, and not at all applicable to Linux. And the NTFS file system in itself also doesn't care about these names. But you're of course right – someone added this as a "safeguard" to the Linux NTFS driver, so that you can't create a file that will later be completely unusable by windows machines. – Marcus Müller Oct 05 '22 at 05:01
  • 9
    That's how DOS was and that's how Windows is. If you look at the link? Its dated 2022 and is for windows. **WINE** is emulating Windows, so it has to work like Windows. – Rohit Gupta Oct 05 '22 at 06:03
  • 7
    Wine is completely irrelevant to the problem at hand. Nothing here is done through a layer of wine. – Marcus Müller Oct 05 '22 at 06:06
  • 4
    His tag is wine – Rohit Gupta Oct 05 '22 at 06:13
  • 4
    Yes, but wine is completely uninvolved with the problem at hand. At no point is wine the thing that refuses to create a file system entry. – Marcus Müller Oct 05 '22 at 07:14
  • 1
    sdb2..4 are ntfs formated – user4089 Oct 05 '22 at 07:42
  • 3
    @user4089 yep, I think that's clear. (but that has nothing to do with wine) – Marcus Müller Oct 05 '22 at 09:05
  • 6
    @MarcusMüller Wine actually is very relevant here because OP wants to use these dirs _for Wine_. Thus even if OP decided to disable this safeguard and make these directories anyway, the end result would still be completely unusable by Wine. Sounds like an issue that's certainly worth mentioning. (Also, OP did actually try creating these dirs "through a layer of Wine" as well.) – TooTea Oct 06 '22 at 08:26
  • 1
    that's how DOS was but that **isn't how Windows is**. You can create files in Windows with those names without any issue by adding the \\?\ prefix. Windows just don't allow them by default to maintain backward compatibility with DOS – phuclv Oct 06 '22 at 15:21
  • @phuclv sounds like what you're saying is that it is an issue, but it has a mitigation (which many programs dont use and therefore will have problems with this issue) – BeB00 Oct 09 '22 at 02:24