WAD Incorrect results from @FILESIZE

[JohnQSmith]

Since TCC/LE is provided as is without support, I thought I'd cross-post it here since the error also exists in full version of TCC. Here's a link to the post in the TCC/LE forum instead of creating additional entries.

 

[Frank]

Thank you, good idea.
I can confirm the behavior with tcc (from my pc via server-share):

>echo %@filesize[/s /[d2000-01-01,2010-12-31] \\app-server3\Anlagen\fl51\*.*,M]
626
 
>echo %@filesize[/s /[d2000-01-01,2010-12-31] \\app-server3\Anlagen\fl51\bildverarbeitung\*.*,M]
3560
 
>ver /r
 
TCC  13.04.58 x64  Windows 7 [Version 6.1.7601]
TCC Build 58  Windows 7 Build 7601  Service Pack 1
Registered to **********

 

[rconn]

Not a bug. The range arguments are being applied to the directories as well as the files, so the /S isn't traversing directories that don't match the date range.

This has always been a unsettled issue -- some users want directories included in ranges, and other users don't.

 

[Frank]

Not a bug. The range arguments are being applied to the directories as well as the files, so the /S isn't traversing directories that don't match the date range.

This has always been a unsettled issue -- some users want directories included in ranges, and other users don't.

Ok, so it is WAD.
But shouldn't this become settled?
Perhaps by letting the user choose whether to recurse all directories respectively appy the range only to files?
In fact I have very huge directories and want to give my users a kind of fileage-assessment.

 

[Steve Fabian]

Since moving an old file into a directory modifies the directory, it "w" timestamp is changed. 99.9% of my accesses do not care what the directory dates are, only files. The complimentary issue is even worse - let directory A and its subdirectory B be older than the date range of interest, but let B's subdirectory C contain a file in the selected range. It will not be reported!

Since the issue is raised relating to @FILESIZE, not @DIRECTORYSIZE, I would like to see the DESIGN changed - when a request is made for members of a directory hierarchy within a specific date range, ALL matching members should be included, even if there is a directory level in the path to the matching member which does not match. I would compare this to trying to locate all 25-year old soldiers in a batallion, and the report ignoring the 25-year olds in units whose commander is older or younger.

 

[Charles Dye]

@FILES & @FILESIZE - Changed the /S behavior to not apply ranges to directories. (Now we'll see who complains more -- the people who want directory ranges or the people who don't!)

I can see wanting ranges applied when the subdirectories are the things being listed or acted on (/A:D), but I can't imagine ever wanting them applied to subdirectories for recursion (/S)!

 

[Steve Fabian]

I use this thread relating to the release of 13.04.62. Is this change of behavior applicable to ALL commands which use both a date range and /S, so the "copy /s /[d] xxx\ yyy\" command will copy all files from the xxx hierarchy that are today's, even if some directory in the path between xxx\ and the file has NOT been modified today, e.g., if the only new file in the tree is "xxx\yyy\zzz\aaa\today.txt", today.txt will be copied?

 

[Frank]

I can see wanting ranges applied when the subdirectories are the things being listed or acted on (/A:D), but I can't imagine ever wanting them applied to subdirectories for recursion (/S)!

Because English isn't my first language, I had to read your statement more than 1 time ;)
So you agree to the way Rex designed it currently, right?

btw:
Now it is working perfectly for me (at least).
I can identify how many old files are wasting how much space.

 

[Charles Dye]

Because English isn't my first language, I had to read your statement more than 1 time ;)

Don't take it personally. My sentences are frequently convoluted enough to give native English speakers pause. (And the forum's helpful conversion of TCC syntax into a smiley doesn't help matters.)

So you agree to the way Rex designed it currently, right?

I have not actually tested that version. But if I understand correctly, the new behavior makes much more sense to my little brain.

 

[Frank]

: D :D