Page 1 of 2
Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-04-16, 14:26 UTC
by Fla$her
When using reverse date sorting (my default), deleting contents inside folders causes them to end up on top, although there is no benefit in this, on the contrary, it's confusing, harms the visual assessment and structuring of viewed or processed content (media and documents) and you often have to spend extra time checking useful changes (creating/modifying).
The suggested option will fix this problem. For example: RestoreDirDateAfterDeletingContent=0/1
Re: Option: don't update the folder date when deleting (or moving from) content
Posted: 2024-04-16, 15:15 UTC
by Dalai
It's not TC which updates directory timestamps but Windows or the underlying file-system. As soon as directory contents are changed (file added, removed) the timestamp changes. Check with other file-managers, Explorer or CMD and you will see the same thing.
Re: Option: don't update the folder date when deleting (or moving from) content
Posted: 2024-04-16, 15:28 UTC
by Fla$her
It doesn't matter. We have the CopyDirTimeStamp and CopyAllTimes options that control the change of timestamps when copying, the same can be done for folders when deleting/moving from them, restoring the previous date, especially since TC has its own deletion mechanism when Win95Delete=0 and VistaDelete=0.
Re: Option: don't update the folder date when deleting (or moving from) content
Posted: 2024-04-17, 11:42 UTC
by petermad
Hmm, it seems to me that the title of this topic should rather be: "Restore folder date after deleting (or moving) content".
It could be nice as an option, but should maybe also include adding files.
Re: Option: restore parent folder date after deleting or moving content
Posted: 2024-04-17, 12:40 UTC
by Fla$her
OK. Changed.
but should maybe also include adding files.
If the copy and move commands had such an option for a target folder, then it would make sense. But saving the date of any folder for any changes is no less a problem than I described.
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-04-18, 08:22 UTC
by ZoSTeR
Full support.
I even wrote a script to prevent that at least for deleting files:
post
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-04-19, 03:11 UTC
by Fla$her
I also did it on AutoIt, but not so much for the button as for reassigning Del and Shift + Del for the current delete command, restoring the date so far only in regular folders.
Code: Select all
;———————————————————————————————————— AU3 ————————————————————————————————————
; Purpose: Delete content with saving parent folder date
; Advice: Bind em_DeleteWithSavingParentDirDate to Delete and Shift+Delete
; Parameters: %S1:~,0
;—————————————————————————————————————————————————————————————————————————————
#NoTrayIcon
$hWnd = WinGetHandle('[ACTIVE]')
If DllCall('user32.dll','int','GetClassName','hwnd',$hWnd,'str','','int',4095)[2] <> 'TTOTAL_CMD' Then Exit
$sPanel = _GetInfo(1000)
Global $sCount = _GetInfo(1004 + $sPanel), $Type = 'Post'
If $sCount = 0 And _GetInfo(1008 + $sPanel) = 1 And _GetInfo(1006 + $sPanel) = 0 Then Exit
$Dir = StringRegExpReplace(ControlGetText($hWnd,'', _GetInfo(8 + $sPanel)),'\\[^\\]+$','')
$IsDir = FileExists($Dir & '\')
If $IsDir Then $Type = 'Send'
If StringLen($Dir) > 2 And $IsDir = 1 Then
If $sCount = 0 Then $sCount = 1
$MDate = FileGetTime($Dir, 0, 1)
Global $DSize = DirGetSize($Dir, 1), $iCount = $DSize[1] + $DSize[2], $NDate, $LDate, $lCount
$rCount = $iCount - $sCount
EndIf
DllCall('user32.dll','int',$Type & 'Message','hwnd',$hWnd,'uint',1075,'wparam',908,'lparam',0)
If IsDeclared('MDate') Then
While $rCount < $iCount
Sleep(500)
$DSize = DirGetSize($Dir, 1)
$iCount = $DSize[1] + $DSize[2]
If $iCount = $lCount Then ExitLoop
$lCount = $iCount
Wend
$NDate = $MDate
While $LDate <> $NDate
$LDate = $NDate
FileSetTime($Dir, $MDate)
Sleep(1000)
$NDate = FileGetTime($Dir, 0, 1)
Wend
If $MDate <> $NDate Then FileSetTime($Dir, $MDate)
Sleep(1000)
If $MDate <> FileGetTime($Dir, 0, 1) Then FileSetTime($Dir, $MDate)
EndIf
Func _GetInfo($i)
Return DllCall('user32.dll','handle','SendMessage','hwnd',$hWnd,'uint',1074,'wparam',$i,'lparam',0)[0]
EndFunc
It's not recommended to create or modify items in a folder during a background operation.
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-05-13, 11:58 UTC
by andry81
Just a suggestion, add a local configuration file for a file system components. For example, to avoid apply it everywhere, instead add file `.wincmd.ini` into a directory you want to alter the behavior:
Code: Select all
[Configuration]
RestoreDirDateAfterDeletingContent=1
RestoreDirDateAfterDeletingContent_RecurseSubdirs=1
RestoreDirDateAfterDeletingContent_DirGlobbing="MyDir*"
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-05-13, 16:44 UTC
by Fla$her
andry81 wrote: ↑2024-05-13, 11:58 UTC
For example, to avoid apply it everywhere,
Code: Select all
RestoreDirDateAfterDeletingContent_RecurseSubdirs=1
Do you want the behavior when selecting from branch mode and search results to be different from the normal folder mode? Why is it necessary?
It's better if one option will regulate all parent dirs in which the disappearance occurs.
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-05-13, 23:50 UTC
by andry81
Fla$her wrote: ↑2024-05-13, 16:44 UTC
andry81 wrote: ↑2024-05-13, 11:58 UTC
For example, to avoid apply it everywhere,
Code: Select all
RestoreDirDateAfterDeletingContent_RecurseSubdirs=1
Do you want the behavior when selecting from branch mode and search results to be different from the normal folder mode? Why is it necessary?
It's better if one option will regulate all parent dirs in which the disappearance occurs.
Just suggest a local config file to override a global config.
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-05-14, 00:13 UTC
by Fla$her
andry81 wrote: ↑2024-05-13, 23:50 UTC
Just suggest a local config file to override a global config.
I don't understand, are you talking about the RedirectSection key? How does this relate to my question?
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-05-15, 06:04 UTC
by andry81
Fla$her wrote: ↑2024-05-14, 00:13 UTC
andry81 wrote: ↑2024-05-13, 23:50 UTC
Just suggest a local config file to override a global config.
I don't understand, are you talking about the RedirectSection key? How does this relate to my question?
Local config enables it for a specific directory instead to add it to the global config, where it would be enabled for all directories, which is definitely is a bad solution.
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-05-15, 06:33 UTC
by Fla$her
I asked, "Why is this necessary?" in relation to _RecurseSubdirs, not _DirGlobbing.
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-05-15, 09:40 UTC
by andry81
Fla$her wrote: ↑2024-05-15, 06:33 UTC
I asked, "Why is this necessary?" in relation to _RecurseSubdirs, not _DirGlobbing.
Because the recursivity or nesting is a part of each directory. You can use multiple levels, for example: Years/Months/Days
So you have to restore the whole directories path.
Or you mean why not use recursion by default? I think it should be optional and does apply to the directory where the local config file is placed.
Re: Option: restore parent folder date after deleting (or moving from it) content
Posted: 2024-05-15, 13:30 UTC
by Fla$her
Once again: pseudo-recursion during deletion is possible only for files selected in DirBranch mode. That's why I asked about your desire to separate the behavior (given the additional key) of 3 modes and pointed out that this separation doesn't look right, safe and expected for many users, i.e. I wouldn't approve of this key with _RecurseSubdirs.
The real recursion concerns considering the entire depth of folders, and since deletion doesn't have file filtering, then there can be no recursion as such.