File create date/time is sticky across file deletion.

[old coot]

I suppose this is just a curiosity, as it occurs in both TCmd and the Windows command shell.
The creation timestamp of a file persists across deletion and re-creation of the file.

[C:\batch]type create-date-problem.btm
@ echo off

  :: Please start this test with a new file that has not been created
  :: AT ANY TIME within this TCmd session.
  :: Run it again, if you want, with the same filename.

  set fname=%1

  echo foo > %fname
  echo File %fname as originally created:
  gosub SHOW %fname
  echo.

  echo File %fname after repeated deletion and recreation:
  do 5
    del %fname >& NUL
    echo foo > %fname
    gosub SHOW %fname
    pause /w3 /c /t Pausing 3 seconds...
  enddo

  quit

:SHOW [file]
  echos   w: %@filedate[%file,w,4] %@filetime[%file,w,s]
  echos    c: %@filedate[%file,c,4] %@filetime[%file,c,s]
  echo    a: %@filedate[%file,a,4] %@filetime[%file,a,s]
  return

[C:\batch]create-date-problem FILEA
File FILEA as originally created:
  w: 2021-11-17 04:43:12   c: 2021-11-17 04:43:12   a: 2021-11-17 04:43:12

File FILEA after repeated deletion and recreation:
  w: 2021-11-17 04:43:12   c: 2021-11-17 04:43:12   a: 2021-11-17 04:43:12
  w: 2021-11-17 04:43:15   c: 2021-11-17 04:43:12   a: 2021-11-17 04:43:15
  w: 2021-11-17 04:43:18   c: 2021-11-17 04:43:12   a: 2021-11-17 04:43:18
  w: 2021-11-17 04:43:21   c: 2021-11-17 04:43:12   a: 2021-11-17 04:43:21
  w: 2021-11-17 04:43:24   c: 2021-11-17 04:43:12   a: 2021-11-17 04:43:24

Note that the create date is the one previously assigned to the file.
This date will persist through numerous deletions and creations, and across multiple TCC windows in TCmd.
The create-date will be reset only when the file is deleted AND TCmd is shut down and relaunched.

This behavior is also present in the Windows command shell.

Given only the above test, this could also be construed as a possible failure in the @filedate/@filetime functions.
But it's not: the same timestamps show up in Windows File Explorer.

 

[Charles Dye]

As usual, Raymond knows all and tells all.

 

[vefatica]

Hmmm! I can detect a 1-second difference ... even much less. Is that because I have 8dot3 names disabled?

v:\> type create.btm
touch /c /q abcdef
echo %@filetime[abcdef,c,s]
del /q abcdef
delay 1
touch /c /q abcdef
echo %@filetime[abcdef,c,s]
del /q abcdef

touch /c /q abcdef
set age1=%@fileage[abcdef,c]
del /q abcdef
delay /m 1
touch /c /q abcdef
set age2=%@fileage[abcdef,c]
del /q abcdef
echo FILEAGE difference: %@eval[(%age2-%age1)/10000000] seconds

v:\> create.btm
12:49:20
12:49:21
FILEAGE difference: 0.0159684 seconds

 

[vefatica]

Is that because I have 8dot3 names disabled?

Yes, indeed. My test was on V:, a SUBST on D: where 8dot3 name creation is disabled. If I perform the test on C:, whete 8dot3 name creation is enabled, I get results like old coot's.

 

[old coot]

The reasons given by Raymond for the tunneling phenomenon:

• Stop LFN from being disconnected from the 8.3 name over certain file-save techniques that are actually deletes and resaves.
• Keep the original creation date over those same file-saves.

So how long can you go after deleting a file before it loses the connection with that old, deleted file? On my system, it is consistently 14-15 seconds. (I didn't bother measuring with less than a one-second granularity.)

That 15-second persistence criterion (which, I would assume, was selected intentionally) seems ridiculously long to achieve those results.

 

[old coot]

Vince, until you mentioned it, I did not even realize it was possible to disable 8.3 filenames. A quick scan of the literature (if you can call it that) shows very mixed opinions as to whether that is a good idea. Here's one quite volatile thread. Crucial (at least at one point) recommended disabling 8.3. I've seen Microsoft blog posts that recommended disablilng. The biggest argument not to disable is that it might break legacy software -- and Wikipedia mentioned compatibility issues, especially with devices like compact flash cards that use VFAT.

It's clear from your results that disabling 8.3 would solve that tunneling issue.

Why do you have it disabled -- and only on part of your system? I would appreciate your comments.

 

[vefatica]

Why do you have it disabled -- and only on part of your system? I would appreciate your comments.

In the past, I have disabled it on all drives. I'm not sure if I've done it on this computer. Disabled except for the system drive may be the default, or I did it on purpose. Last night I issued this command.

fsutil 8dot3name strip /l v:\8dot3.log /s c:

As I read the docs I found, that strips the 8dot3 names on drive c: selectively. It leaves intact any for which there are registry entries. FSUTIL also has another switch ("/f") to "force" the stripping of all of them. When I looked at the log, all the 8dot3 names that were NOT stripped were mostly from OEM-installed stuff (Intel and Dell). There were also many installer registry entries mentioning C:\Users\ADMINI~1\, which doesn't exist.

I think that if I disabled 8dot3namecreation on the system drive without stripping, existing ones would remain intact (and work) but no new ones would be generated.

To read more, issue fsutil 8dot3name and/or fsutil 8dot3name strip /?.

 

[vefatica]

P.S., The log also mentions many like this one, apparently mistaking them for 8dot3 names because of the '~' (or something like that).

C:\Program Files\WindowsApps\Microsoft.Microsoft3DViewer_7.1908.9012.0_neutral_~_8wekyb3d8bbwe  HKCR\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\PackageRepository\Packages\Microsoft.Microsoft3DViewer_7.1908.9012.0_neutral_~_8wekyb3d8bbwe

 

[David Marcus]

I have 8dot3 disabled on my personal computers. I didn't remove the filenames that already existed. Most programs these days don't need the 8dot3 filenames.

 

[vefatica]

I just disabled them on the system drive. The ones that were there still work.

v:\> fsutil 8dot3name set C: 1
Successfully disabled 8dot3name generation on C:

v:\> C:\PROGRA~1\Dell\

c:\progra~1\dell>