PDIR and @LABEL questions

[Steve Fabian]

I ran the command below on both my Win7Pro 64b system (64b TCC 15.01.52) and my WinXP Pro 32b system (same TCC build).

On the WinXP system:
cxs/[s1]/[!descript.ion C:\tmp\*] C:\ G:\ > C:\TMP\20130801.CAT

On the Win7 system:
cxs /[s1] /[!descript.ion C:\tmp\*] C:\ E:\ I:\ > C:\TMP\20130801.CAT

where on both systems:

cxs is an alias : pdir/t:wu/nj/og/s/a:-d/(z r dy-m-d"Z"th:m:s @inode[*] -15@label[*] @serial[*] fpnq)

pdir is an alias : *pdir /ne /d /p

Note that the drives other than C: on each system are locally USB-mounted physical or virtual (solid state) disk drives.

1/ On the Win7 system only, executing pdir /[d] from another TCC instance multiple times, many minutes apart, with nothing else active on the system, showed the same write timestamp and size of the report file. Executing either TAIL or TAIL /F (and immediately interrupting it) on the file and repeating pdir /[d] showed very large size increases. Repeated many times with identical observation. Just using pdir /[d] on the WinXP system always showed a size increase and timestamp change. Is this related to a change between WinXP and Win7 on how files are buffered?

2/ @LABEL reported the correct drive label except when reporting a file on a drive other than on C: if the fpqn field of PDIR actually included quotemarks. In that event it reported the label of the C: drive (of the respective systems). I realize that in a PDIR field the * parameter (@label[*]) is NOT just the drive letter followed by colon, so it is technically an invalid argument. However, the @SERIAL function and the VOL command both accept the same input and report correctly.

 

[Steve Fabian]

Forgot to mention.
3/ In the %TMP directory both on the WinXP and the Win7 systems during the execution of PDIR files with names like EXEhhh.tmp (where hhh is a 3 or 4 digit hexadecimal number) were created and deleted, never more than one at a time. Which reporting field causes this? Obviously it substantially increases the total execution time, so I would like to eliminate it if possible.

 

[rconn]

Forgot to mention.
3/ In the %TMP directory both on the WinXP and the Win7 systems during the execution of PDIR files with names like EXEhhh.tmp (where hhh is a 3 or 4 digit hexadecimal number) were created and deleted, never more than one at a time. Which reporting field causes this? Obviously it substantially increases the total execution time, so I would like to eliminate it if possible.

They're not being created by PDIR (or TCC).

 

[rconn]

1/ On the Win7 system only, executing pdir /[d] from another TCC instance multiple times, many minutes apart, with nothing else active on the system, showed the same write timestamp and size of the report file. Executing either TAIL or TAIL /F (and immediately interrupting it) on the file and repeating pdir /[d] showed very large size increases. Repeated many times with identical observation. Just using pdir /[d] on the WinXP system always showed a size increase and timestamp change. Is this related to a change between WinXP and Win7 on how files are buffered?

That's a Windows filesystem issue. You'll have to ask Microsoft.

2/ @LABEL reported the correct drive label except when reporting a file on a drive other than on C: if the fpqn field of PDIR actually included quotemarks. In that event it reported the label of the C: drive (of the respective systems). I realize that in a PDIR field the * parameter (@label[*]) is NOT just the drive letter followed by colon, so it is technically an invalid argument. However, the @SERIAL function and the VOL command both accept the same input and report correctly.

I don't know that saying "since some functions accept invalid arguments, all functions should accept invalid arguments" makes for a compelling case. In this case, it's the different Windows APIs that are behaving differently. I definitely do *not* think that it's a good idea to secretly alter the user's specified argument to match a perceived "better" argument on a per-API basis.

 

[Steve Fabian]

Re 1/ - Your response implies "it's a MS change". Now that I know I need to live with it, even though it is yet another backward step by Win7.

Re 2/ - That's not the intended characterization. My point is that some functions return the presumably intended result even if their argument is invalid, some report error, but @LABEL often returns wrong information without ever reporting the user error. I just submitted a FEEDBACK IDEA regarding this issue.

Re 3/ - Since the temporary files were created and removed when only TCC executing PDIR was active, it was a consequence of PDIR. It may have been done by the Windows APIs while processing the functions @LABEL or @INODE, possibly because the functions had invalid arguments. It would benefit users if this could be traced.