WAD TOUCH /R[acw]?

[vefatica]

The help says the reference filename must immediately follow /R. The examples show an intervening space. How it actually works seems to depend on whether /R has a modifier (acw).

Here, no modifier and a space, it seems to have done the right thing (modified the write time on 2.txt to match that of 1.txt). It's the same without a space.

v:\touchtest> do f in *.txt ( echo %f & do i in /c caw ( echo %i %@filedate[%f,%i] %@filetime[%f,%i] ))
1.txt
c 2013-07-05 12:57
a 2013-07-05 12:57
w 2013-07-05 13:10
2.txt
c 2013-07-05 12:57
a 2013-07-05 12:57
w 2013-07-05 13:11
 
v:\touchtest> touch /r 1.txt 2.txt
2013-07-05 13:10:49.955  V:\touchtest\2.txt
 
v:\touchtest> do f in *.txt ( echo %f & do i in /c caw ( echo %i %@filedate[%f,%i] %@filetime[%f,%i] ))
1.txt
c 2013-07-05 12:57
a 2013-07-05 12:57
w 2013-07-05 13:10
2.txt
c 2013-07-05 12:57
a 2013-07-05 12:57
w 2013-07-05 13:10

Now lets throw put a modifier on /R. When there's a space, it seems /R is ignored, and both files are touched and get the current time as write time.

v:\touchtest> touch /rc 1.txt 2.txt
2013-07-05 13:21:35.165  V:\touchtest\1.txt
2013-07-05 13:21:35.165  V:\touchtest\2.txt
 
v:\touchtest> do f in *.txt ( echo %f & do i in /c caw ( echo %i %@filedate[%f,%i] %@filetime[%f,%i] ))
1.txt
c 2013-07-05 12:57
a 2013-07-05 12:57
w 2013-07-05 13:21
2.txt
c 2013-07-05 12:57
a 2013-07-05 12:57
w 2013-07-05 13:21

With a modifier and no space, only one file is touched (good) but it gets the current time as write time (so the reference file was somehow ignored).

v:\touchtest> touch /rc1.txt 2.txt
2013-07-05 13:24:38.498  V:\touchtest\2.txt
 
v:\touchtest> do f in *.txt ( echo %f & do i in /c caw ( echo %i %@filedate[%f,%i] %@filetime[%f,%i] ))
1.txt
c 2013-07-05 12:57
a 2013-07-05 12:57
w 2013-07-05 13:21
2.txt
c 2013-07-05 12:57
a 2013-07-05 12:57
w 2013-07-05 13:24

It doesn't seem to be working well.

I don't see how no_space can ever work with a modifier. What would "/Rabc.txt" mean? Is the switch "/Ra" and the file "bc.txt" or the switch "/R" and the file "abc.txt"? (DWIM parser required here.)

P.S. The last test is the same even if I try to be more precise:

touch /rc"1.txt" 2.txt

 

[rconn]

When the help file says the file name must immediately follow the /R option, it means as the next argument, not appended to the /R. (That's the same syntax used everywhere else in the help file for those sort of arguments.)

 

[rconn]

The help says the reference filename must immediately follow /R. The examples show an intervening space. How it actually works seems to depend on whether /R has a modifier (acw).

WAD - your syntax is wrong.

Try it again with the required ':' after the /R:

touch /r:c 1.txt 2.txt

 

[vefatica]

When the help file says the file name must immediately follow the /R option, it means as the next argument, not appended to the /R. (That's the same syntax used everywhere else in the help file for those sort of arguments.)

OK, it's in one place in the help, but not in one or two more where it might be. FFIND's /T"..." and /E"..." always bugged me (no space allowed).

 

[vefatica]

You can't do all the times at once (/R:acw reffile), can you?. That would have been convenient.

 

[rconn]

You can't do all the times at once (/R:acw reffile), can you?. That would have been convenient.

Why? (Why would you want to do that, not why would it be convenient.)

Nobody has asked for that in the last 20 years, so I'm wondering -- why now?

 

[vefatica]

Why? (Why would you want to do that, not why would it be convenient.)

Nobody has asked for that in the last 20 years, so I'm wondering -- why now?

I wanted to make two files as identical as possible to make a point/ask a question in an technet forum.
http://social.technet.microsoft.com...36f1a1621/rationale-for-open-file-url-warning

 

[Steve Fabian]

The only reason I can see doing it is to create a (partial) drive image.

I do not remember when I last looked at an access time. For me it could be useful for removing files not used for a long time, if I had a disk space problem, which I don't. Of course, there are environments in which information security requires knowledge of last access time, but IMHO those environments also need to keep track of the accessor's identity and access type, ranging from just finding out what files exist to modifying file properties or even content. Just keeping track of access type is insufficient. And how about virus scanners? Unless well designed, they can change

I very rarely look at creation time, and I like it to indicate when the current instance of a file was created.

Except in very rare and unusual situations only the time when a file body was last written, i.e., when the content of a file was modified, is relevant to me. The time of changing any other file property (name, access control, "attributes", etc.) is irrelevant. IMHO it is too bad that the default of operations equivalent to TCC's COPY and MOVE commands on POSIX-type target systems is to make file modification timestamp that of the modification of the specific instance, i.e., the time of the copy or move, rather than copying the modification timestamp of the source. This is a default for the POSIX-type commands, not of the POSIX file systems, and command options are available to change the command behaviors to match the TCC defaults. The disadvantage of the POSIX default is that one cannot distinguish refreshing of the file from actually changing it without accessing the file content, which nearly always requires more resources and more time. The same point applies to operating systems and file systems which consider modifying a file property a modification of the file.

Sorry for the overlong response to a simple item.

 

[vefatica]

I do not remember when I last looked at an access time.

Last access time has been disabled by default in NTFS since Vista.

v:\> fsutil behavior query DisableLastAccess
DisableLastAccess = 1