date changing of existing file when rename copied file

[nice]

- at the left:
* selected: \Plugins\wcx\Total7zip\7z.dll (date: 20.11.2021)

- at the right
- enter in 7z archive: 7z2107.exe
* 7z.dll in archive (date: 26.12.2021)

- at the left:
* 7z.dll is locked (dll is loaded)

- copy 7z.dll from right to left:
* file is already used
- select "rename"
* file date of existing file at the left changed to date of copied file (file is not overwritten)

- at the left
- file - change attributes - change date/time
* error setting the following attribute: timestamp (date+time)

[ghisler(Author)]

I could not reproduce it: Only the date of the unpacked file is being set.
I tried with the internal 7zip unpacker, total7zip, and the 7zip plugin.

[nice]

can reproduce only when archive is official 7zip installer (7z2107.exe).
on other archives, can't reproduce.

"error setting date/time attribute on opened files" is a (another) bug. another programs can do that. no admin rights needed.

[ghisler(Author)]

I did try with the official installer.
What do you use to unpack? The internal 7zip unpacker, total7zip, and the 7zip plugin?

[nice]

TC 10.50_b8 x32 fresh install, total7zip, updated libraries
https://youtu.be/-VDIiysf2e4

[ghisler(Author)]

So the problem must be in Total7zip - TC itself doesn't set the file timestamp when unpacking with a plugin.

[nice]

how does plugin know the old name? is it handled by TC?

i have found that after unpacking 7z.dll1 (renamed file), and setting date to it, it sets date to 7z.dll:Zone.Identifier, but not to 7z.dll itself (existing file), and not to renamed file
and modification to 7z.dll:Zone.Identifier is made by TOTALCMD.EXE (not by total7zip.wcx)
unpacked renamed file does not contain Zone.Identifier (but contain when unpacked non-renamed)

[Usher]

2nice
I think that you are trying to overwrite files existing in 7-zip folder. In this case you can't overwrite 7zip.dll as it in use and locked when you are unpacking any 7z archive, including 7-zip installer, of course. You may have also problems with overwriting 7-zip.dll which is used and locked by system as shell extension.

Regarding Zone.Identifier: it is written to alternate data stream (ADS) when you download any file, f.e. 7-zip installer. TC tries to keep this setting for any file unpacked from the downloaded archive.
I have observed that in some cases file gets current timestamp when ADS is changed. In older Windows timestamp was changed when you just used "Summary" tab from file properties and clicked OK.
I don't know how TC manages ZoneID, but ADS seems to be available for editing also when the file is in use. In this case the current timestamp is set after editing ADS though the file itself hasn't been replaced and it's timestamp shouldn't be updated.

[ghisler(Author)]

how does plugin know the old name? is it handled by TC?

Probably from the name of the file inside the archive.

[nice]

The file is RENAMED. The plugin does not know the OLD name.
Total Commander changes Zone.Identifier of the wrong file. of ORIGINAL file, not RENAMED. So it's changed Last Modification date.
Probably this is not a common bug, or rare bug, but isn't is a bug? But NOT "Behaviour which will not be changed".
Reproducible only on Total7zip, because what others archivers are? MultiArc? it even doesn't allow to rename.

[Usher]

2nice
You can turn OFF Zone.Id propagation by TC. It's described in TC Help. Just add to your wincmd.ini in [Configuration] section the following line:

Code: Select all

WantZoneData=0

However, Zone.Id may be propagated by other programs, including 7-zip itself. There may be created or propagated also other streams - by other programs, by shell extensions or by the system itself. For example, the system itself may add ADS for every internet message saved as *.eml or *.nws (like Outlook Express or Windows Live Mail do) and change timestamps to current:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/f1adfb03-a5ca-49e5-9f0e-c01b7c56c2e3

[nice]

i'm talking about a bug. it set Zone.Identifier to wrong file. not to turn off Zone.Identifier for any file. i don't know why it's required and who uses it. is anyone consider Zone.Identifier (and window "this file is downloaded from internet") useful?
but anyone does not understand that it set Zone.Identifier to wrong file. i checked it with process monitor, and it's made by totalcmd.
Why not acknowledge the bug? say it's a rare bug and no one wants to fix it, but it's a bug!

[ghisler(Author)]

I was finally able to reproduce the problem with Total7zip! Moving the thread back to the bugs forum.

[ghisler(Author)]

This should be fixed in RC3, please test!
1. Install Total7zip plugin
2. Download a 7zip file with your Web browser, e.g. https://www.7-zip.org/a/7z2201-src.7z
3. Check with Files - "Calculate occupied space" that it has a zone identifier
4. Open the 7zip with enter and extract a file with F5
5. Extract the SAME file with F5 and choose "Rename"
6. Check with Files - "Calculate occupied space" that both extracted files have a zone identifier

[nice]

Confirmed