Declined New Command to Update a File Timestamp

[Craig T. Dedo]

You should create a new command to update one or more of a file's timestamps. The default behavior (without any command qualifiers) should be to make sure that the file's Create Timestamp is no later than the file's Update Timestamp. I have numerous files where for some unknown reason the Create Timestamp is much later than the Modify Timestamp, sometimes many years later. Obviously, such a situation is absurd. I should be able to easily change the Create Timestamp so that it is the same as or earlier than the Modify Timestamp.

I don't have a specific name for this command that I consider to be particularly good. However, either UPDATE or TIMESTAMP come to mind. I am open to good alternatives. One alternative is to enhance the TOUCH command to allow the user to set the Modification Timestamp to be less than or equal to the Creation Timestamp for all files in a single directory or an entire directory tree.

What I want is a simple way to specify the following without having to write my own program:
Create_Timestamp = Modification_Timestamp +/- Delta_Time
where Delta_Time is specified as a combination of date and time that is either added to or subtracted from the Modification_Timestamp.
If the sign is +, then the Creation_Timestamp is later than the Modification_Timestamp, i.e., Delta_Time is added to Modification_Timestamp.
If the sign is -, then the Creation_Timestamp is earlier than the Modification_Timestamp, i.e., Delta_Time is subtracted from Modification_Timestamp.

 

[samintz]

Have you looked at the TOUCH command?

 

[Craig T. Dedo]

Have you looked at the TOUCH command?

Yes. It has a lot of abilities but it does not have the ability to set the creation date to be less than or equal to the modification date for all files in a single directory or an entire directory tree. One possibility of implementing what I want is to add this capability to the TOUCH command.

 

[vefatica]

It's easy to get a file a file whose creation date is later than the modified date. Just COPY or MOVE a file to a destination where it doesn't already exist. That's standard procedure. Expect it to happen if you're archiving files.

v:\> del .ses
Deleting V:\.ses
     1 file deleted

v:\> copy Z:\.ses v:\
Z:\.ses => V:\.ses
     1 file copied

v:\> filetimes z:\.ses
Created:  2021-12-03 13:28:55
Accessed: 2021-12-04 16:36:24
Modified: 2021-12-04 16:28:57

v:\> filetimes v:\.ses
Created:  2021-12-04 16:36:24 <--- later than modified
Accessed: 2021-12-04 16:36:24
Modified: 2021-12-04 16:28:57

And it's fairly easy to change the creation date/time to the modified date/time if the former is later than the latter for a collection of files. [Below, change the file specification to do the files of your choice. I did only one.]

v:\> do f in /a:-d .ses (if %@fileage["%f",c] GT %@fileage["%f",w] touch /Dc%@filedate["%f",w] /Tc%@filetime["%f",w,s] "%f" )
2021-12-04 16:28:57.000  V:\.ses

v:\> filetimes v:\.ses
Created:  2021-12-04 16:28:57
Accessed: 2021-12-04 16:36:24
Modified: 2021-12-04 16:28:57

I haven't tried it but you could probably do that for a whole tree by specifying "/S" in the DO command.

Be careful using TOUCH. Test it first using the "/N" (do nothing) option. And don't a space between "/Dc" ["/Tc"] and the date [time]. Doing that cost me half an hour!

FILETIMES is a plugin command.

 

[rconn]

You should create a new command to update one or more of a file's timestamps. The default behavior (without any command qualifiers) should be to make sure that the file's Create Timestamp is no later than the file's Update Timestamp. I have numerous files where for some unknown reason the Create Timestamp is much later than the Modify Timestamp, sometimes many years later. Obviously, such a situation is absurd. I should be able to easily change the Create Timestamp so that it is the same as or earlier than the Modify Timestamp.

I don't have a specific name for this command that I consider to be particularly good. However, either UPDATE or TIMESTAMP come to mind. I am open to good alternatives. One alternative is to enhance the TOUCH command to allow the user to set the Modification Timestamp to be less than or equal to the Creation Timestamp for all files in a single directory or an entire directory tree.

What I want is a simple way to specify the following without having to write my own program:
Create_Timestamp = Modification_Timestamp +/- Delta_Time
where Delta_Time is specified as a combination of date and time that is either added to or subtracted from the Modification_Timestamp.
If the sign is +, then the Creation_Timestamp is later than the Modification_Timestamp, i.e., Delta_Time is added to Modification_Timestamp.
If the sign is -, then the Creation_Timestamp is earlier than the Modification_Timestamp, i.e., Delta_Time is subtracted from Modification_Timestamp.

I don't understand why you would want / need this (other than to make you happy when you look at a DIR listing?).

It's perfectly normal for create timestamps to sometimes be "newer" than the last write timestamp, depending on how the file was copied / moved / unzip'd / etc.

 

[mfarah]

While we're at this, millisecond adjustment support for this new command (if not TOUCH itself) should be added, given that NTFS fully supports them in a file's timestamp.

 

[rconn]

While we're at this, millisecond adjustment support for this new command (if not TOUCH itself) should be added, given that NTFS fully supports them in a file's timestamp.

Because you *can* doesn't mean you *will* (or *should*). Do you have a need to change the ms? Or the ns?

 

[mfarah]

At work, we have a policy of setting the compiled *.class files with the same timestamp as the .java files they come from, to ease up auditing of what classes actually change. It's not difficult to touch them so they'll have the same timestamp down to the second... but then, the milliseconds difference remains (where the .class has ".000" and thus is "older" than its corresponding source with its, say, ".666" value), which screws the report up.

So far, I've dealt with this by touching my .java files with their own timestamp, forcing them all to be ".000", but it's annoying and stinks of a kluge (and if I ever forget to do so before doing a delivery...).

 

[rconn]

Still not sure I get the point. The timestamp is going to be in 100ns increments, so changing it at ms resolution isn't going to give them the same time.

 

[mfarah]

Let's go with 100ns increments, then.

OTOH, come to think of it, this functionality WOULD be a good candidate for a command implemented through a plugin, for those weirdos (i.e., me) that need this. I imagine the underlying Windows APIs should be able to get and set a file(/directory/junction/etc.)'s "file time", shouldn't it?

 

[vefatica]

I reckon the SetFileTime API is all that's needed. You can specify any combination of create, write, and access times giving times as FILETIME structures, namely the number of 100-nanosecond intervals since 1/1/1601 00:00:00 (compare to TCC's "ages").

What if you use TOUCH's "/R reference_file" option to give each .class the same timestamp at the source. That will make them match right down to 100-nanoseconds.

v:\touch> touch /c foo.txt
2023-05-04 16:55:07.764  V:\touch\foo.txt

v:\touch> touch /c bar.txt
2023-05-04 16:55:19.355  V:\touch\bar.txt

REM see that the timestamps differ
v:\touch> do flag in /L a c w (echo %@fileage[foo.txt,%flag] %@fileage[bar.txt,%flag])
133276929077640728 133276929193554576
133276929077640728 133276929193554576
133276929077640000 133276929193550000

REM make them all agree
v:\touch> do flag in /L a c w (touch /r:%flag foo.txt bar.txt)
2023-05-04 16:57:56.175  V:\touch\bar.txt
2023-05-04 16:55:07.764  V:\touch\bar.txt
2023-05-04 16:55:07.764  V:\touch\bar.txt

REM now they agree
v:\touch> do flag in /L a c w (echo %@fileage[foo.txt,%flag] %@fileage[bar.txt,%flag])
133276930761750000 133276930761750000
133276929077640728 133276929077640728
133276929077640000 133276929077640000

 

[vefatica]

Here's another one where the files were not created with TOUCH. All the timestamps have 100nsec resolution and after using foo.txt as the reference file, the timestamps agree and still have 100nsec resolution.

v:\touch> do flag in /L a c w (echo %@fileage[foo.txt,%flag] %@fileage[bar.txt,%flag])
133276938736868961 133276938811010459
133276938736868961 133276938811010459
133276938736868961 133276938811010459

v:\touch> do flag in /L a c w (touch /r:%flag foo.txt bar.txt)
2023-05-04 17:11:13.686  V:\touch\bar.txt
2023-05-04 17:11:13.686  V:\touch\bar.txt
2023-05-04 17:11:13.686  V:\touch\bar.txt

v:\touch> do flag in /L a c w (echo %@fileage[foo.txt,%flag] %@fileage[bar.txt,%flag])
133276938736868961 133276938736868961
133276938736868961 133276938736868961
133276938736868961 133276938736868961

 

[mfarah]

What if you use TOUCH's "/R reference_file" option to give each .class the same timestamp at the source. That will make them match right down to 100-nanoseconds.

This works perfectly for what I need. Thanks!

 

[rconn]

Let's go with 100ns increments, then.

You really want to enter a 7-digit number for the fractional second?

 

[mfarah]

You really want to enter a 7-digit number for the fractional second?

Not really — I'll tell the computer do that part of the work. But the point remains that if NTFS supports a file time down 100ns increments, then TCMD should let the user get and set the timestamp of a file down to that granularity instead of stopping at seconds (*)... something that IS already supported with TOUCH /R.

Perhaps leaving TOUCH as-is and adding a separate command to get and set an object's file time, although only by specifying its 64-bit value as a long number, would be the best solution. Vefatica, I'll be asking you about the nitty-gritty of writing plugins.




(*) A few months ago, I had to show my kid how the FAT system stored the time down to TWO-SECOND intervals, as the spec was one bit too short. He didn't believe me until he saw it with his own eyes.

 

[rconn]

Not really — I'll tell the computer do that part of the work. But the point remains that if NTFS supports a file time down 100ns increments, then TCMD should let the user get and set the timestamp of a file down to that granularity instead of stopping at seconds (*)... something that IS already supported with TOUCH /R.

TCC doesn't stop at seconds; you can set it down to 1/100ths of a second with TOUCH.

 

[mfarah]

TCC doesn't stop at seconds; you can set it down to 1/100ths of a second with TOUCH.

Indeed. I didn't know this, as it seems to be undocumented. I remember trying, not long ago, the ".789" thing and getting the same error as here, but it didn't occur to me that two digits for the milliseconds would pass.

a) Shouldn't be too hard to add the third digit, so as to support individual milliseconds?

b) Note how using only one digit for the milliseconds produces an unexpected result ("12:34:56,070" instead of "12:34:56,700").

 

[vefatica]

Perhaps leaving TOUCH as-is and adding a separate command to get and set an object's file time, although only by specifying its 64-bit value as a long number, would be the best solution. Vefatica, I'll be asking you about the nitty-gritty of writing plugins.

If you know the "C" programming language, the nitty-gritty of plugin writing is in the plugin Software Development Kit. I have made (and never used) a "TCC Plugin" template for Developer's Studio; it's a little more than nitty-gritty.

How would such a command work? As things stand, you'd be pretty much stuck having to manually enter a 64-bit integer (a FILETIME) or a time with seconds to 7 decimal places. I don't think TCC will be much help constructing such input.

 

[rconn]

b) Note how using only one digit for the milliseconds produces an unexpected result ("12:34:56,070" instead of "12:34:56,700").

Doesn't seem unexpected to me; a single digit does not mean the single digit * 10.

 

[Charles G]

Indeed. I didn't know this, as it seems to be undocumented. I remember trying, not long ago, the ".789" thing and getting the same error as here, but it didn't occur to me that two digits for the milliseconds would pass.

a) Shouldn't be too hard to add the third digit, so as to support individual milliseconds?

b) Note how using only one digit for the milliseconds produces an unexpected result ("12:34:56,070" instead of "12:34:56,700").



View attachment 3906

What is your PD alias?

 

[mfarah]

Doesn't seem unexpected to me; a single digit does not mean the single digit * 10.

Sorry, Rex, but it totally means that. "0.7" is the same as "0.70" (or "0.700", etc.), not "0.07".

 

[mfarah]

What is your PD alias?

'tis the one:

pd=*pdir /D/A-d/(dymd thmsd a z fpn)

Part of a full bunch that I use constantly:

I still have to work one in that will produce all the file stamps (a, c, w) for a given file.

 

[Charles G]

'tis the one:

pd=*pdir /D/A-d/(dymd thmsd a z fpn)

Part of a full bunch that I use constantly:

View attachment 3907


I still have to work one in that will produce all the file stamps (a, c, w) for a given file.

i'd be interested if you'd like to post all your alias's and weed out those that are specific to your system....

 

[Charles G]

'tis the one:

pd=*pdir /D/A-d/(dymd thmsd a z fpn)

Part of a full bunch that I use constantly:

View attachment 3907


I still have to work one in that will produce all the file stamps (a, c, w) for a given file.

be easwier if you would just copy them into a code block on here... not just as an image....

 

[mfarah]

i'd be interested if you'd like to post all your alias's and weed out those that are specific to your system....

I can do that, but should definitely be in a new thread (so as not to go further off-topic here).

 

[Charles G]

I can do that, but should definitely be in a new thread (so as not to go further off-topic here).

I started the suggestion Here - - -

 

[rconn]

Sorry, Rex, but it totally means that. "0.7" is the same as "0.70" (or "0.700", etc.), not "0.07".

Not in this context. If you entered "1:1:1" for a time, would you expect the parser to interpret that as 10:10:10?

 

[mfarah]

Not in this context. If you entered "1:1:1" for a time, would you expect the parser to interpret that as 10:10:10?

That may parse for hours, minutes and seconds, but we're talking about the milliseconds (after the decimal point/comma) here, so I do expect ".7" to mean ".700", not ".070" or ".007".

 

[AnrDaemon]

I'd say, your work policy should round the times to whole seconds precision in the report, if not to 2s.
Or even better, simply assume that if a class is newer than source, it was compiled recently, which is a common assumption.

 

[rconn]

That may parse for hours, minutes and seconds, but we're talking about the milliseconds (after the decimal point/comma) here, so I do expect ".7" to mean ".700", not ".070" or ".007

TOUCH does not support millisecond times.