#1155 MSYS commands mishandle trailing whitespace

[Keith Marshall]

The autoconf-2.62 testsuite attempts to execute the following script fragment:--

# Can we create directories with trailing whitespaces in their name?
rm -rf 'tdir /'
mkdir 'tdir ' && touch 'tdir /tfile' 2>/dev/null
if test -f 'tdir /tfile'; then
func_sanitize_dir_name () { echo "$@"; }
else
func_sanitize_dir_name () { echo "$@" | sed 's/ *$//'; }
fi
rm -rf 'tdir /'

The "mkdir 'tdir '" command silently discards the explicit trailing whitespace, successfully creating a directory called 'tdir'; (even if the command is rewritten as "mkdir 'tdir /'", it still does this).

The two "rm -rf 'tdir /'" commands fail, with a "tdir /: No such file or directory" error; the non-zero (=1) exit status causes the autoconf testsuite to abort.

Rewriting the "rm" commands as "rm -rf 'tdir '" results in successful removal of the 'tdir' directory; i.e. without the trailing "/", rm behaves as mkdir, insofar as it trims explicit trailing whitespace, but the behaviour is inconsistent, in the presence of the trailing "/".

Besides the inconsistent handling of the trailing "/", in the presence of trailing explicit whitespace, there are two issues here:--

1) POSIX *requires* rm to silently ignore specified entities which are not found, when the "-f" option is in effect; thus it *should* *never* report "No such file or directory", when invoked with "-f", nor should it report a non-zero exit status, in the absence of any other error. This is a defect in MSYS rm.

2) MSVCRT's _mkdir() function is perfectly happy to create directories, with explicit trailing whitespace in their names; e.g. _mkdir("foo /") will create a directory called 'foo '. Once so created, an MSYS ls command, which does *not* refer to it, (either explicitly or implicitly), will show it to exist, but any MSYS command which attempts to access it, or even to refer to it in any way, will fail with a "foo : No such file or directory" error.

[Keith Marshall]

Logged In: YES
user_id=823908
Originator: YES

Just so there is no misunderstanding, I consider the silent trimming of explicit trailing whitespace to be the principal bug here; silently creating 'foo', when the user explicitly wanted 'foo ', simply cannot be correct behaviour, no matter how asinine we may consider the notion of trailing whitespace on file or directory names to be.

The issue of the inappropriate rm exit status, while also a bug, is secondary to this issue; it may merit a separate bug report.

[Earnie Boyd]

Cesar, is this issue still valid?

[Keith Marshall]

I'm not Cesar, but from my perspective this remains unresolved. Running the test case again today, as I originally described it, I see no evidence of any change in behaviour.