WAD del unable to delete files ending in "."

[nickles]

Given the following file entry, del isn't able to delete the file (mind the "." at the end):

06.12.2015 13:37 167 ___A___________ DSSET-~2 dsset-sub-example.net.

del "dsset-sub.example.net."
TCC: (Sys) The system cannot find the file specified.
"D:\temp\down\xx\1\dsset-sub.example.net."
0 files deleted

The same happens with ` quoting, or ' quoting, or w/o quoting. So, resorting to short file names:

del dsset-~2
Deleting D:\temp\down\xx\1\dsset-sub.example.net.
TCC: (Sys) The system cannot find the file specified.
"D:\temp\down\xx\1\dsset-sub.example.net."
0 files deleted 1 failed

The same happens with any quoting.

Only GnuWin32's rm des the trick (note: GnuWin32 is a native port not using cygwin.dll or msys.dll).

The file name does not contain any characters above 127.

 

[Charles Dye]

That's an invalid filename; the last character cannot be a period.

Using the short filename to delete it is the right idea, and will usually work in CMD.EXE. But TCC picks up the (illegal) long name when it canonicalizes the filename. FixNames might also help with this situation.

 

[rconn]

As Charles said, it's an invalid filename.

The reason it can't be deleted isn't because of TCC, it's because the Windows DeleteFile API won't accept that name.

 

[nickles]

Nice explanation. But what if I only had TCC at my hands. How would I get rid of the file? rm.exe (Native Win32!, MSys2 and CygWin) can do it...

Interestingly (as Charles indicated) CMD *does* remove the file. Is this WAD?

 

[jbanaszczyk]

Are you sure?
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#paths

"The limits are in the windows shell -- not in Windows or NT."
It looks, that it is not invalid filename, but not supported by cmd.

 

[vefatica]

That depends on how you read it. When I read

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.

I think Windows does not support it.

 

[jbanaszczyk]

For example:

 

[jbanaszczyk]

NTFS in file system level does not filter almost any characters.

Limitations are built into the shell (cmd, tcc, win explorer)

as an example: windows properly displays file name " " (space alone) and ampersand (formally prohibited)

 

[rconn]

It's possible (though not in Windows Explorer, CMD, PowerShell, or TCC) to create NTFS filenames with embedded chararacters like %, ^, <. >, |, *, ?, etc.

But only a complete dunderhead (i.e., a Linux developer) would do that.

 

[Charles Dye]

But only a complete dunderhead (i.e., a Linux developer) would do that.

/Linux developer/Mac user/

 

[rconn]

Nice explanation. But what if I only had TCC at my hands. How would I get rid of the file? rm.exe (Native Win32!, MSys2 and CygWin) can do it...

Interestingly (as Charles indicated) CMD *does* remove the file. Is this WAD?

If you want SFN support in TCC (which I STRONGLY advise against, as it's an excellent way to obliterate the contents of your disk), you need to turn it on in OPTION / Startup / Search for SFNs.

But sooner or later, you'll be sorry ...

 

[jbanaszczyk]

Why Linux???? My roots are Unix.
In PL we are talking: "if you walked among the crows caw as they" (probably in english: "when in Rome, do as the Romans do")

It is a Windows world. Filesystem' behoviour is not dependent on master operating system (NTFS and Windows), +1 for Microsoft. Filesystem does nothing for "shell special characters".
Filesystem supports (for example) Unix/Linux native file paths, as expected.

But I don't expect that the best windows shell (TCC :) of course) should support non-windows context. If I would use file name similar to (NTFS valid) "X:<?>" or "nul" I will use proper shell/operating system.

And going back to the origin: IMHO "dsset-sub.example.net." is a valid filename, but not supported by windows.

Best regards :)

 

[nickles]

Once again:

1) As I remarked above: "Interestingly (as Charles indicated) CMD *does* remove the file." So alone for compatibility's sake TCC should be able to do it.
2) The file was created unpacking a WinRar archive.
3) I don't care what "dunderhead" created that file (and for what motives - maybe he's a virus programmer), I want to get rid of it with TCC, not having to resort to CMD or rm.exe.

 

[rconn]

Once again:

1) As I remarked above: "Interestingly (as Charles indicated) CMD *does* remove the file." So alone for compatibility's sake TCC should be able to do it.
2) The file was created unpacking a WinRar archive.
3) I don't care what "dunderhead" created that file (and for what motives - maybe he's a virus programmer), I want to get rid of it with TCC, not having to resort to CMD or rm.exe.

Did you turn on SFN support in TCC?

There is no way (in any Windows shell) to get rid of that file using an LFN.

 

[nickles]

Yup, "Search for SFNs" is checked in OPTION.

cmd.exe proves the opposite...

 

[Charles Dye]

1) As I remarked above: "Interestingly (as Charles indicated) CMD *does* remove the file." So alone for compatibility's sake TCC should be able to do it.

I'm pretty sure that the behavior you see is because TCC canonicalizes everything. (Note that in both of your original commands, the error message gives the full long filename, though you never type it that way.)

And I think that 99.99% of the time, TCC's behavior is the Right Thing. Canonicalization not only cleans up case and shows you the true path, it also has the neat side effect (in Rex's implementation) of expanding directory aliases. I would hate to see the default behavior changed just for the occasional bad filename.

 

[Charles Dye]

Oh, yeah. You can delete that file -- in TCC or CMD.EXE -- with:

del "\\?\D:\temp\down\xx\1\dsset-sub.example.net."

Similar syntax to rename it, copy it, etc. I think this syntax bypasses TCC's canonicalization; Rex would know for sure.

 

[nickles]

In cmd.exe you type: "del dsset-~2"

Ok, I can live with this behavior (having the necessary tools at hand), but on the other side, this is NOT compatible with cmd.exe (and what about the users not having rm.exe ready?).
But in that case: don't anyone stress the argument of tcc's compatbility anymore...

 

[vefatica]

Nice one Charles!

v:\> ver

TCC  19.00.25  Windows 7 [Version 6.1.7601]

v:\> touch /c \\?\h:\work\x.
2015-12-18 11:13:36.391  \\?\H:\work\x.

v:\> d x*
2015-12-18  11:13  0  x.
2015-12-03  00:20  1,683  xavtemp.btm

v:\> del \\?\h:\work\x.
Deleting \\?\H:\work\x.
  1 file deleted

v:\> d x*
2015-12-03  00:20  1,683  xavtemp.btm