Option: restore parent folder date after deleting (or moving from it) content

[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

[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.

[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.

[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.

[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.

[ZoSTeR]

 
Full support.

I even wrote a script to prevent that at least for deleting files: post

[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.

DeleteWithSavingParentDirDate.au3

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.

[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*"

[Fla$her]

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.

[andry81]

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.

[Fla$her]

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?

[andry81]

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.

[Fla$her]

I asked, "Why is this necessary?" in relation to _RecurseSubdirs, not _DirGlobbing.

[andry81]

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.

[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.