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.
WAD Incorrect results from @FILESIZE
- Thread starter JohnQSmith
- Start date
Thank you, good idea.
I can confirm the behavior with tcc (from my pc via server-share):
I can confirm the behavior with tcc (from my pc via server-share):
Code:
>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 **********
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.
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.
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.
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.
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)!
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?
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.
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.)
I have not actually tested that version. But if I understand correctly, the new behavior makes much more sense to my little brain.
Similar threads
