Behavior in pack files: %$DATE$ don't work -and- no error message on invalid names

[funkymonk]

TC11.00 final x32


I have just tried to use the new env var %$DATE$ in the pack files dialog:

Code: Select all

zip:C:\somedir\%$DATE:YMD$ - test.zip

Apparently this env var cannot be used here. Sad but ok. I hope this will be supported in the future.


However: Once a ":" is part of the file name (which is an invalid char in file names), like

Code: Select all

left:right.zip

TC still creates a file with the substring left of the ":" as file name.

In the examples above: "left" and "%$DATE".
The file has no extension and the file size is 0.

I consider this a bug.
If a filename is invalid, an error message should be shown. In no case should the file name be changed without notice.
And of course it is unexpected to receive a 0 byte file instead of an archive.

Moderator message from: Stefan2 » 2023-08-03, 06:12 UTC

Subject adjusted by moderator to reflect the real content of this posting.
Please take care yourself next time, thank you.
This way others can tell if they want to open and read this thread or not,
and also can find the answer too, once they are searching the forum before posting for an already given answer.

[Horst.Epp]

If you read the forum and the help, you would know that your syntax is wrong.
Look at this button and see how the variable is to be used %|$DATE:

Code: Select all

TOTALCMD#BAR#DATA
"C:\Program Files\7-Zip\7z.exe"
a %T"%B"_%|$DATE:YMD_hm| @%UL -aoa -mmt -mx9 -ssw -stl -ssp -y
C:\Program Files\7-Zip\7zFM.exe
Pack selected

0
-1

[funkymonk]

@Horst.Epp

If you would have read my post properly, you would know that I have used the pack dialog with TC's internal zip (not a button).

In this dialog your syntax does not seem to work either.
In fact, an error appears: "Error writing new ZIP file, disk may be full!"
@ghisler: I guess the error message in this case could be way better...

Apart, the problem with ":" in the file name has nothing to do with the DATE env var.

[Hacker]

Doesn't "name:colon" create a file "name" with an alternate data stream named "colon"?

Roman

[funkymonk]

Doesn't "name:colon" create a file "name" with an alternate data stream named "colon"?

Roman

I agree, ":" is commonly used to specify such streams.
However, there is no stream in the created files (from the 1st post).
Even if they had a data stream, they should certainly not be empty (0 bytes) but contain the compressed data...

[ghisler(Author)]

Neither F5 copy nor Alt+F5 pack support environment variables in the edit box.
However, you can use a button or internal command with the following options:
Command: cm_packfiles
Parameters: /T="%T%|$DATE:YMD_hm| - test.zip"

Explanation:
When you want to use $DATE in a field like "Command" which accepts environment variables, write it as %$DATE%.
If you want to use it in a field like "Parameters" which accepts placeholders like %P or %T, you need to write it as %|$DATE|

[funkymonk]

Neither F5 copy nor Alt+F5 pack support environment variables in the edit box.

Sure, as said in the 1st post: "Apparently this env var cannot be used here. Sad but ok."

I'm way more concerned about the consequences/bug? when specifying a ":" in the file name (file name changed without notification, 0B byte file size) ...

[ghisler(Author)]

Windows uses ":" to separate names and streams, so what you get from left:right is a stream "right" in file named "left".

[funkymonk]

Windows uses ":" to separate names and streams, so what you get from left:right is a stream "right" in file named "left".

True. I have checked again, and the file indeed contains the streams.

Still: Why is it 0 bytes? Shouldn't it contain compressed data? Actually, it was created for packing files...

In any case there is some inconsistency:
In "create new file" (Shift+F4) no files with streams can be created (":" is rejected as part of the file name).
In "pack files" it works. It doesn't look like that was intentional. It looks more like a coincidence...

[batchman61]

Afaik it is by NTFS Design.
NTFS file size does not include size of streams, thus 0 Bytes in your example.

[ghisler(Author)]

Yes, that's correct - otherwise it would confuse users a lot, because things like the "zone identifier" when you download a file are also stored in extra streams.

Would you block streams in the pack function too?

[ghisler(Author)]

Moderator message

Moved to will not be changed

[funkymonk]

Sorry, I was gone for some weeks.

I have checked my concerns again and would like to give another 2ct on TC’s behavior when using streams in zip file names (all tested with a fresh and clean ini).

When packing into a data stream, e.g., “test.zip:xxx”, the file “test.zip” and the stream “xxx” within that file is created. Fine.
The file has size 0 and the stream has the size of the compressed data. Also fine.

However: Even if correct from a technical perspective, this behavior might be very confusing/annoying to many users, since

1. I suspect that many users are not familiar with file streams and don’t know how to work with them.
2. Even if we ignore those users,
   I could not find any way to unpack the data from the stream with just a plain TC. Maybe I have missed something.
   Thus: Is it true that TC (without additional tools/plugins) can pack into a stream but not unpack from it? This would be very “imbalanced”.
3. If this is true, I suggest to at least show a warning.
   The warning could be similar to the one that appears when packing files with Unicode names. Also similar to handling Unicode, the ini could receive an option, like:
   PackStream= (0) warn when using streams, (1) don't allow and show an error when using streams, (2) just allow streams without warning.

---

BTW: When packing data into an already existing stream (of an existing file), the stream is simply overwritten.
No warning, no question on how to proceed.
This is also questionable and I suggest to display a dialog like the one when overwriting files (copy/move).

[ghisler(Author)]

Sounds like a good idea to show a warning which can be disabled.

[funkymonk]

Thank you for considering!

I would still be interested in the question whether TC can unpack from file streams. Maybe I have missed something. Thank you!