How to create a file withe the name "test."

[Herbert Kleebauer]

:: To create a file with the name "test." on a NTFS
:: file system use (testet in WIN10):

echo hello world>test.::$DATA

:: the file can't be deleted with
del test
del test.
:: and also not with explorer
:: but only by deleting all test.* files with
:: del test.*

::this also doesn't work

type test.
more test.
more <test.
more test.::$DATA

:: only this works

more <test.::$DATA

[JJ]

Nice trick.

[R.Wieser]

Herbert,

> echo hello world>test.::$DATA
>
> :: the file can't be deleted with
> del test
> del test.

del test.::$DATA

doesn't work either.

Yep, you can create Alternate Data Streams, but thats pretty-much all the
support Windows has for it. :-|

> :: but only by deleting all test.* files with
> :: del test.*

del test?

also works and has a lesser impact.

But if you ever find yourself in that "can't delete" situation just move all
"test*" files to another, temporary folder, as it leaves the "can't find it"
file behind. Delete the offending file (using a wildcard) and move the
moved files back. Might even be put into a nice batchfile. :-)

It does make me think a long way back to DOS, where adding an, IIRC, ALT 254
(which didn't display) would cause similar "can't find, can't delete"
problems.

Regards,
Rudy Wieser

[JJ]

On Mon, 1 May 2023 12:33:29 +0200, R.Wieser wrote:
>
> Yep, you can create Alternate Data Streams, but thats pretty-much all the
> support Windows has for it. :-|

With the previously mentioned trick, we can at least see the contents. e.g.

dir > out:dat
more < out:dat

[R.Wieser]

JJ

> With the previously mentioned trick, we can at least see the
> contents. e.g.

True, but that was not what the post was about.

Regards,
Rudy Wieser

[Herbert Kleebauer]

On 01.05.2023 16:52, JJ wrote:

> With the previously mentioned trick, we can at least see the contents. e.g.
>
> dir > out:dat
> more < out:dat

But only if the file name is not a single letter:


echo hello>test
echo world>t

for %%i in (t*.*) do echo abc>%%i:xyz
dir t*.* /r

for %%i in (t*.*) do more <%%i:xyz

[R.Wieser]

Herbert,

> But only if the file name is not a single letter:

Mentioning the why of that would have been nice : a single letter followed
by a colon is interpreted as a drive letter.

And that means that the exception to your exception is that something like

echo hello>c:$data

works - even though not creating an alternate data stream : you just get a
file with the name "$data" - in whatever the current folder on C: is. :-)

Regards,
Rudy Wieser

[R.Wieser]

Herbert,

> :: To create a file with the name "test." on a NTFS
> :: file system use (testet in WIN10):
>
> echo hello world>test.::$DATA

I just found/realized you applied a two tricks there : Besides placing a
colon at the end of the "test" filename the "::$DATA" *looks* like an
alternate data stream reference, but the "hello world" text ends up in the
"test." file (and not the ADS). At least, not on my XP OS.

Also, a quick test replacing the "$data" with "$bla" shows that thats not
accepted. IOW, it looks like the "::$data" part is parsed as an ADS, but
than somehow discarded.

Microsoft : where"bugs with seniority" become "features". :-)

Regards,
Rudy Wieser

[Herbert Kleebauer]

On 02.05.2023 08:21, R.Wieser wrote:

>> But only if the file name is not a single letter:
>
> Mentioning the why of that would have been nice : a single letter followed
> by a colon is interpreted as a drive letter.
>
> And that means that the exception to your exception is that something like
>
> echo hello>c:$data

But the correct syntax would be:

echo hello>c::$data (doesn't work)
echo hello>c:xyz:$data (does work, but not as expected: xyz:$data:$DATA)
echo hello>c:xyz (does work, but no alternate stream)

For two letter file names instead of one letter names all is ok:

echo hello>bc::$data (does work)
echo hello>bc:xyz:$data (does work)
echo hello>bc:xyz (does work)


The real problem is, if you use a "for %%i in (*.*) loop to
write or read alternate data streams and there are file
names with a single letter, you get in trouble. That's
the way I got aware of the problem. And it also doesn't
help to add a "." to the single letter file name, because
then not the file "c" but the file "c." is created (which
gets you into even bigger trouble).

[Herbert Kleebauer]

On 02.05.2023 10:30, R.Wieser wrote:
> Herbert,
>
>> :: To create a file with the name "test." on a NTFS
>> :: file system use (testet in WIN10):
>>
>> echo hello world>test.::$DATA
>
> I just found/realized you applied a two tricks there : Besides placing a
> colon at the end of the "test" filename the "::$DATA" *looks* like an
> alternate data stream reference, but the "hello world" text ends up in the
> "test." file (and not the ADS). At least, not on my XP OS.

filename:alternate_stream_name:
if you omit the stream name, the standard stream is used

echo abc>test.txt
echo abc>test.txt::$DATA

are the same.


You can omit the $DATA here: echo abc>test.txt:xzz:
but not here: echo abc>test.txt::

[JJ]

On Tue, 2 May 2023 11:02:49 +0200, Herbert Kleebauer wrote:
>
> echo hello>c::$data (doesn't work)

Is it possible to create a file/directory with a completely empty name even
with special tool other than those which directly modifies the disk sectors?

[R.Wieser]

Herbert,

> But the correct syntax would be:

"Houston, we have a problem"

I believe you, but I can't write to an ADS using that double-double-colon
way. I however can using a single double-colon.

echo hello> test::$DATA

works, but stuffs the "hello" into the "test" file.

echo hello> test::$BLA

doesn't work. At all.

echo hello> test:$DATA
echo hello> test:$BLA

works, the "hello" gets stuffed ito the "$DATA" / "$BLA" ADS (the "test"
file stays empty.)

> echo hello>c:xyz:$data (does work, but not as expected: xyz:$data:$DATA)

:-) That, "but not as expected" is what your thread started with.

> The real problem is, if you use a "for %%i in (*.*) loop to
> write or read alternate data streams and there are file
> names with a single letter, you get in trouble.

True, but not for the reason you made it appear as. You get in trouble
(doesn't work as expected) *regardless* of the "::$DATA" postfix.

> because then not the file "c" but the file "c." is created (which
> gets you into even bigger trouble).

:-) Luckily I realized that before trying it out. <phew!>

>echo abc>test.txt
>echo abc>test.txt::$DATA
>
>are the same.

<whistle> I only realized that that was what happened after posting my
previous message (It has been a while after I looked into ADS).

Regards,
Rudy Wieser

[Ammammata]

R.Wieser formulated the question :

> It does make me think a long way back to DOS, where adding an, IIRC, ALT 254
> (which didn't display) would cause similar "can't find, can't delete"
> problems.

excel version 2 (two) had a similar trick on the installation floppy
disk: the hidden file, whose name included a "special" space, was
added/removed by the setup program, to avoid multiple installations

using norton utilities it was possible to make changes :-)

--
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

[JJ]

On Tue, 2 May 2023 10:30:47 +0200, R.Wieser wrote:
>
> Also, a quick test replacing the "$data" with "$bla" shows that thats not
> accepted. IOW, it looks like the "::$data" part is parsed as an ADS, but
> than somehow discarded.

The "$DATA" part is the third field of the ":" separated non UNC file system
object name syntax, which is meant for NTFS file/directory attribute names.
The attribute names are predefined names. They can't be user defined.

$DATA is the attribute name which specifies the file/directory data. It's
the only attribute which is applicable on all file system types.

There are other NTFS attributes such as $ATTRIBUTE_LIST, $BITMAP, and
$INDEX_ALLOCATION, but none of them are accessible for common file usage.

[Herbert Kleebauer]

Just do some experimenting with the "\\?\" prefix:

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

For file I/O, the "\\?\" prefix to a path string tells the Windows APIs
to disable all string parsing and to send the string that follows it
straight to the file system.

Because it turns off automatic expansion of the path string, the
"\\?\" prefix also allows the use of ".." and "." in the path names,
which can be useful if you are attempting to perform operations on a
file with these otherwise reserved relative path specifiers as part
of the fully qualified path.


There is also a "\\.\" prefix:

By comparison, if you have a 100 port serial expansion board
installed and want to open COM56, you cannot open it using "COM56"
because there is no predefined NT namespace for COM56. You will
need to open it using "\\.\COM56" because "\\.\" goes directly to
the device namespace without attempting to locate a predefined alias.

[Konrad]

One common method to use special file names like 'test.' is to use the
\\?\ prefix together with absolute paths.
e.g.:

copy nul \\?\C:\MyDir\test.
del \\?\C:\MyDir\test.