Re: incorrect(?) errno value in msdosfs

From: pluknet <pluknet_at_gmail.com>
Date: Tue, 6 Feb 2007 11:14:37 +0300
On 06/02/07, Oliver Fromme <olli_at_lurza.secnetix.de> wrote:
> pluknet <pluknet_at_gmail.com> wrote:
>  > I have discovered an unexpected behavior. If I perform a search
>  > operation in the directory for non-existing files, then I get
>  > the EINVAL value on msdosfs filesystem instead of
>  > the ENOENT value returned.
>
> EINVAL should be returned if you try to lookup an invalid
> file name.  ENOENT should be returned if the file name is
> valid but does not exist.
>
> Remember that MSDOSFS is a lot stricter than UFS, as far
> as valid file names are concerned.  For example, the only
> characters forbidden in UFS file names are '/' (slash) and
> '\0' (zero byte), because slash is the directory separator
> and zero byte is the string terminator.  On the other hand,
> quite a lot of characters are not allowed in MSDOSFS file
> names, including the wildcards '?' and '*'.
>
>  > For example if I run the next command on msdosfs filesystem,
>  > this is what I get:
>  >
>  > bash-2.05b$ ls /mnt/msdosfs/*.nonexistent
>  > ls: /mnt/msdosfs/*.nonexistent: Invalid argument
>
> That's correct behaviour.  Let me explain:
>
> When your shell encounters unquoted wildcards ('*' in this
> case), it retrieves a directory listing and tries to match
> the entries with your pattern.  If there is no match, the
> default behaviour of most bourne-compatible shells
> (including bash) is to use the pattern as-is, i.e. as if
> it was quoted.  In other words, it tries to look for a
> literal file name of "*.nonexistent".
>
> As I explained above, the '*' character is illegal in
> MSDOSFS file names, so the lookup function returns EINVAL
> without even trying to locate that file name in the
> directory.
>
>  > instead of:
>  >
>  > bash-2.05b$ ls /mnt/msdosfs/*.nonexistent
>  > ls: /mnt/msdosfs/*.nonexistent: No such file or directory
>
> That would be incorrect behaviour.
>
> Try to look up a file name that's valid (but doesn't exist
> either).  You will certainly get ENOENT.  If you still get
> EINVAL, it's time to submit a PR.  :-)
>
> Best regards
>    Oliver
>
> --
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783
> Any opinions expressed in this message are personal to the author and may
> not necessarily reflect the opinions of secnetix GmbH & Co KG in any way.
> FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
>
> "And believe me, as a C++ programmer, I don't hesitate to question
> the decisions of language designers.  After a decent amount of C++
> exposure, Python's flaws seem ridiculously small." -- Ville Vainio
>

Thanks for the explanation.
I have forgotten about a not allowed wildcards :(

wbr,
pluknet
Received on Tue Feb 06 2007 - 07:14:40 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:05 UTC