mkdir: cannot create directory ... : Invalid argument

[Albretch Mueller]

1) From the live DVD, I am running:

$ sudo uname -a
Linux debian 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02)
x86_64 GNU/Linux

2) using as desktop environment:

echo $XDG_CURRENT_DESKTOP
XFCE
~
I am able to make a directory while I am in "/home/user" but not
inside of a directory which I mounted by clicking on their GUI. Why
would that be?

$ pwd
/home/user
$ findmnt -n -o SOURCE --target "$(pwd)"
overlay

$ _DIR="WeltUndWirkungsprinzip2.Aufl."
_DIR02=$(printf %s "${_DIR}" | jq -sRr @uri)
if [ "${_DIR}" == "${_DIR02}" ]; then
echo "// __ \"${_DIR}\" == \"${_DIR02}\"|"
mkdir --parents --verbose "${_DIR02}"
fi
// __ "WeltUndWirkungsprinzip2.Aufl." == "WeltUndWirkungsprinzip2.Aufl."|
mkdir: created directory 'WeltUndWirkungsprinzip2.Aufl.'
$

while in the Windows NT directory:

$ pwd
/media/user/<...>

$ findmnt -n -o SOURCE --target "$(pwd)"
/dev/sda1

_DIR="WeltUndWirkungsprinzip2.Aufl."
_DIR02=$(printf %s "${_DIR}" | jq -sRr @uri)
if [ "${_DIR}" == "${_DIR02}" ]; then
echo "// __ \"${_DIR}\" == \"${_DIR02}\"|"
mkdir --parents --verbose "${_DIR02}"
fi
// __ "WeltUndWirkungsprinzip2.Aufl." == "WeltUndWirkungsprinzip2.Aufl."|
mkdir: cannot create directory ‘WeltUndWirkungsprinzip2.Aufl.’: Invalid argument
$ ls -l "${_DIR02}"
ls: cannot access 'WeltUndWirkungsprinzip2.Aufl.': No such file or directory
$ cd "${_DIR02}"
bash: cd: WeltUndWirkungsprinzip2.Aufl.: No such file or directory
$

$ sudo df -Th | grep "Filesystem\|overlay\|^/dev/sd"
Filesystem Type Size Used Avail Use% Mounted on
tmpfs tmpfs 7.8G 1.2G 6.6G 16% /run/live/overlay
overlay overlay 7.8G 1.2G 6.6G 16% /
/dev/sda1 fuseblk 286G 274G 12G 96% /media/user/<...>
$

$ pwd
/home/user
$ cd WeltUndWirkungsprinzip2.Aufl./
$ pwd
/home/user/WeltUndWirkungsprinzip2.Aufl.
$ echo "1 2 3 X Y Z" > file.txt
$ ls -l
total 4
-rw-r--r-- 1 user user 12 Feb 12 20:57 file.txt
$ _SCR=$(pwd)
$ cd ..
$ pwd
/home/user
$ echo "${_SCR}"
/home/user/WeltUndWirkungsprinzip2.Aufl.
$ rsync --verbose --archive "${_SCR}" "/media/user/<...>"
sending incremental file list
rsync: [generator] recv_generator: mkdir
"/media/user/<...>/WeltUndWirkungsprinzip2.Aufl." failed: Invalid
argument (22)
*** Skipping any contents from this failed directory ***
WeltUndWirkungsprinzip2.Aufl./

sent 118 bytes received 20 bytes 276.00 bytes/sec
total size is 12 speedup is 0.09
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1333) [sender=3.2.3]
$ ls -l "/media/user/<...>/WeltUndWirkungsprinzip2.Aufl."
ls: cannot access '/media/user/<...>/WeltUndWirkungsprinzip2.Aufl.':
No such file or directory
$


I thought the problem related the encoding of characters of the URL
from which I was that string, but it is not the case. So, the problem
seems to relate to a dot as the last character of the name of a
subdirectory on Windows NT filesystems mounted by fuseblk. Is that the
case? I had never heard of such thing.

lbrtchx

[Greg Wooledge]

On Sun, Feb 12, 2023 at 09:04:35PM +0000, Albretch Mueller wrote:
> while in the Windows NT directory:

Is the NT file system mounted read-only, or read-write?

Is it mounted using ntfs-3g, or the native Linux driver? The latter
probably can't mount it read-write.

There may also be something to do with which version of Windows created
the file system. I think there are multiple versions of NTFS.

[Nito]

On Sun, Feb 12, 2023 at 21:04:35 +0000, Albretch Mueller wrote:
> while in the Windows NT directory:

> [...]

> mkdir: cannot create directory ‘WeltUndWirkungsprinzip2.Aufl.’: Invalid argument

> [...]

> /dev/sda1 fuseblk 286G 274G 12G 96% /media/user/<...>
>

> [...] So, the problem

> seems to relate to a dot as the last character of the name of a
> subdirectory on Windows NT filesystems mounted by fuseblk. Is that the
> case? I had never heard of such thing.

Yes, Win32/NTFS has a bunch of arbitrary seeming path restrictions, magic
normalisation and illegal names. A single or two trailing dot(s) are
one of the things not valid in Win32 namepsace, in this case due to
path normalisation.
(There are special ways to bypass normalisation, but chances are you’d
have trouble to interact with or even delete such a dir from Windows)

See:
https://learn.microsoft.com/en-us/archive/blogs/jeremykuhne/path-normalization
and the relevant ntfs-3g option the mounting GUI probably uses:
https://manpages.debian.org/bullseye/ntfs-3g/ntfs-3g.8.en.html#windows_names

[David Wright]

On Sun 12 Feb 2023 at 21:04:35 (+0000), Albretch Mueller wrote:
>
> I thought the problem related the encoding of characters of the URL
> from which I was that string, but it is not the case. So, the problem
> seems to relate to a dot as the last character of the name of a
> subdirectory on Windows NT filesystems mounted by fuseblk. Is that the
> case? I had never heard of such thing.

My goto page for this sort of thing is:

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file

which says:

“Do not end a file or directory name with a space or a period.
Although the underlying file system may support such names,
the Windows shell and user interface does not. However, it is
acceptable to specify a period as the first character of a name.
For example, ".temp".”

Cheers,
David.

[Albretch Mueller]

Hmm! Technically speaking I wonder why that would be.
The only way around the problem is using another filesystem or URL
encoding the whole name when Microsoft doesn't like it, but at times
you are squeezing away some time to code while you are at work where
they only use MS crap, but they would grant you a WSL installation ...
I was also having those kinds of problems because I work on corpora
research and we need to work with huge amounts of data, so as a way to
keep tabs on "what came from where", I replicate the URLs locally as
best as I can. I realize that idea wasn't as safe as I thought.
Thank you to all,
lbrtchx

[David Wright]

On Mon 13 Feb 2023 at 01:44:15 (+0000), Albretch Mueller wrote:
> On 2/12/23, David Wright <deb...@lionunicorn.co.uk> wrote:
> > On Sun 12 Feb 2023 at 21:04:35 (+0000), Albretch Mueller wrote:
> >>
> >> I thought the problem related the encoding of characters of the URL
> >> from which I was that string, but it is not the case. So, the problem
> >> seems to relate to a dot as the last character of the name of a
> >> subdirectory on Windows NT filesystems mounted by fuseblk. Is that the
> >> case? I had never heard of such thing.
> >
> > My goto page for this sort of thing is:
> >
> > https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
> >
> > which says:
> >
> > “Do not end a file or directory name with a space or a period.
> > Although the underlying file system may support such names,
> > the Windows shell and user interface does not. However, it is
> > acceptable to specify a period as the first character of a name.
> > For example, ".temp".”
>
> Hmm! Technically speaking I wonder why that would be.

IIRC, if you go back far enough, 8.3 filenames (and 6.3 even earlier)
were actually stored as FILENAMEEXT; IOW, the dot was implied but not
stored. The volume label, LABELSTRING, was also eleven characters in
size, but had no dot added to it when displayed.

Consequently, the filename "ABCDEFGH." would be indistinguishable
from "ABCDEFGH", and was disallowed.

BTW, I didn't bother to look at the code in your example because
I didn't see any relevance to the error/question. AFAICT you're
just trying to create a file (or directory) on different filesystems.
You don't need a load of shell toothpicks to demonstrate the problem.

> The only way around the problem is using another filesystem or URL
> encoding the whole name when Microsoft doesn't like it, but at times
> you are squeezing away some time to code while you are at work where
> they only use MS crap, but they would grant you a WSL installation ...
> I was also having those kinds of problems because I work on corpora
> research and we need to work with huge amounts of data, so as a way to
> keep tabs on "what came from where", I replicate the URLs locally as
> best as I can. I realize that idea wasn't as safe as I thought.

The obvious way to store your URLs safely is encoded, as shown at:

https://www.w3schools.com/tags/ref_urlencode.ASP

Cheers,
David.

[Greg Wooledge]

On Sun, Feb 12, 2023 at 10:56:18PM -0600, David Wright wrote:
> BTW, I didn't bother to look at the code in your example because
> I didn't see any relevance to the error/question. AFAICT you're
> just trying to create a file (or directory) on different filesystems.
> You don't need a load of shell toothpicks to demonstrate the problem.

That was the same issue I had. I couldn't dis-entangle all of the
crazy shell stuff he was doing to try to get to the root of the actual
problem.

Had there been something straightforward like:

me@deblive:~$ cd /mnt/whatever
me@deblive:/mnt/whatever$ mkdir foo
me@deblive:/mnt/whatever$ mkdir bar.
Error message here.
me@deblive:/mnt/whatever$ mount | grep whatever
File system and mount options shown here.

then we might have got to the heart of the problem much more easily.