[WCX] SetFolderDate 1.3.0.0

[iG0R]

Thanks for the answer.
I've already written my own PS script - https://www.ghisler.ch/board/viewtopic.php?p=458513#p458513

[mikedepetris]

Hi, I am still using dirdate very often. I do have just one little problem I was never able to fix, that is when the write operation fails for some reason the plugin gives error and returns.
Would it be possible to have an option to continue the operation to the end, and then report the list of failures?
The error is "Failed to get last write time."
It seems to occour for long pathnames, for example when used on c:\Users\<USER>\AppData
Thank you.

[tbeu]

Yes, I could easily add an option to continue on write error. What I am rather more interested is the actual reason behind the error which I am unable to reproduce. Can you determine exactly under which circumstances the write error occurs.? The message box should give a hint to the path. Which OS and which FS do you have?

[mikedepetris]

Example of "Failed to set last write time."
"c:\Users\mikedepetris\AppData\LocalLow\Oracle\Java\jdk11.0.9_x64"
dir has only one file:
"jdk11.0.964.msi"

last lines of "c:\Users\MIKEDE~1\AppData\Local\Temp\totalcmd.log":
29/03/2025 14:01:36: Pack(Error: Write error): C:\Users\MIKEDE~1\AppData\Local\Temp\LocalLow.dirdate
29/03/2025 14:01:45: Pack: C:\Users\MIKEDE~1\AppData\Local\Temp\Microsoft.dirdate
29/03/2025 14:01:56: Pack(Error: Write error): C:\Users\MIKEDE~1\AppData\Local\Temp\LocalLow.dirdate
29/03/2025 14:02:04: Pack(Error: Write error): C:\Users\MIKEDE~1\AppData\Local\Temp\Oracle.dirdate
29/03/2025 14:03:17: Pack(Error: Write error): C:\Users\MIKEDE~1\AppData\Local\Temp\jdk11.0.9_x64.dirdate

I also extract details with the lister plugin for the dir:
Item: "c:\Users\mikedepetris\AppData\LocalLow\Oracle\Java\jdk11.0.9_x64\"

Security Descriptor:
Security Descriptor, Valid, 148 bytes
Contains DACL that is set up to support automatic propagation of inheritable ACEs to existing child objects.
Has a DACL.
Has a DACL that is protected from being modified by inheritable ACEs.
Is in self-relative format.

Owner:
SID: "MSI\mikedepetris", S-1-5-21-881913937-2251148314-2346521520-1002, User SID

Primary Group:
SID: "MSI\NESSUNO", S-1-5-21-881913937-2251148314-2346521520-513, Group SID

DACL:
Entry 1
Trustee
SID: "NT AUTHORITY\SYSTEM", S-1-5-18, Well-known Group SID
Access Rights
Specific Access Rights
Grant add subdirectory
Grant traverse
Grant delete child
Grant read extended attributes
Grant write extended attributes
Grant read attributes
Grant write attributes
Standard Access Rights
Grant delete access
Grant read access to the owner, group, and DACL
Grant write access to the DACL
Grant write access to the owner
Grant synchronize access
Generic Access Rights
Inheritance
Applies to child containers
Applies to child objects
Applies to this object only.
Entry 2
Trustee
SID: "BUILTIN\Administrators", S-1-5-32-544, Alias SID
Access Rights
Specific Access Rights
Grant add subdirectory
Grant traverse
Grant delete child
Grant read extended attributes
Grant write extended attributes
Grant read attributes
Grant write attributes
Standard Access Rights
Grant delete access
Grant read access to the owner, group, and DACL
Grant write access to the DACL
Grant write access to the owner
Grant synchronize access
Generic Access Rights
Inheritance
Applies to child containers
Applies to child objects
Applies to this object only.
Entry 3
Trustee
SID: "", S-1-1-0, Well-known Group SID
Access Rights
Specific Access Rights
Grant read extended attributes
Grant read attributes
Standard Access Rights
Grant read access to the owner, group, and DACL
Grant synchronize access
Generic Access Rights
Inheritance
Applies to child containers
Applies to child objects
Applies to this object only.

[sqa_wizard]

May this is due to the "recursive" setting.
The MSI file (archive) is detected as folder, but 7-zip does not find a date in this file.
You can comment out or invalidate the "ProgPath7z" setting at SetFolderDate.ini temporarily to avoid such behaviour.

[mikedepetris]

I have not a SetFolderDate.ini file for the WCX, I have it for the SetFolderDate.exe only.
But you gave me an Idea, I tryed the standalone exe and worked well. I did some more tests and experiments and found out that wcx worked when tc was run as admin. I realized the dir had wrong permissions set, I corrected them, and now it's working.
The problem with the wcx remains, it stops with "Failed to set last write time" in those cases.

EDITED:
A special case seems to be:
"c:\Users\mikedepetris\AppData\Local\Google\Chrome\User Data"
here the error appears randomly, so I guess Chrome is saving its data with wrong permissions or the directories may appear locked while Chrome is running. This failure appears even if tc is run as admin.

[tbeu]

Sorry, I am confused about comments mentioning SetFolderDate.exe or 7zip. Don't we speak about about the WCX: https://totalcmd.net/plugring/setfolderdate64.html ?

[mikedepetris]

Sorry, I am confused about comments mentioning SetFolderDate.exe or 7zip. Don't we speak about about the WCX: https://totalcmd.net/plugring/setfolderdate64.html ?

yes, that's the subject and the one I'm using, I just tested the .exe to check for different behavior.

[tbeu]

@mikedeptris Can you please check if the updated version 1.3.1.0 fixes the error. I did not yet add an option to skip errors.

[mikedepetris]

@mikedeptris Can you please check if the updated version 1.3.1.0 fixes the error. I did not yet add an option to skip errors.

tried and got
"GetLastWriteTime failed with error 2: The system cannot find the file specified."
on "c:\Users\mikedepetris\AppData\Local\Google\Chrome\<somewhere>"

trying a second time I did not get the error
May it be that the wcx first reads all the files and fails is it goes to set the timestamp of a directory that has just been deleted? It's the Chrome cache so it may be possible.
This is also consistent with the fact I have more errors when running over top dirs that take a lot of time.

[tbeu]

Thanks for the feedback. Yes, it's a race condition as the wcx first collects all files and then runs the file-time manipulation on that file tree. If a file is deleted meanwhile, it returns the error you observe, if a file is added meanwhile it's not counted in.

[mikedepetris]

Thanks for the feedback. Yes, it's a race condition as the wcx first collects all files and then runs the file-time manipulation on that file tree. If a file is deleted meanwhile, it returns the error you observe, if a file is added meanwhile it's not counted in.

do you think you can make it complete the action eventually reporting any issue?

[tbeu]

Please give the updated version 1.3.2.0 a try. Errors are silently ignored now.

[mikedepetris]

Thank you, for the first time I have "AppData" updated!
So happy.