forfiles help

[flotsam]

I am trying to use the forfiles command to create a report of files older than x days, that reside on my file server.

I have the following:

forfiles -s -py:\ -m*.* -d-365 -c"cmd /c echo @FDATE @FSIZE @PATH\@FILE" | sort /O C:\filereports\365daysold.txt

The above runs perfectly as it is. The drive listed is not my file server, it is another mapped drive that I was using for testing. To run this against my file server it would look like the following:

forfiles -s -pu:\ -m*.* -d-365 -c"cmd /c echo @FDATE @FSIZE @PATH\@FILE" | sort /O C:\filereports\365daysold.txt

The problem is that when I try and run it on this drive, I get the following output:

-snip
19941216 4896 u:\ACCPAY\PAGENET.XLS
19941220 3300 u:\ACCPAY\PARKWAY.XLS
FindNextFile - unexpected return code=6 (on FindNext) line 317
Warning : Access denied (during recursion) line 302
Warning : Access denied (on FindFirst) line 274
-EOF

I get the same error if I run the command logged into windows as myself, or the domain admin, remote (drive map), or locally on the server.

Yet I have no problem running a simple dir /s command either logged in under my user accout, or the domain admin.

Can anyone tell me where I screwed up?

Thanks, Chad

 

[aquias]

My first thought on this is the NTFS permissions. I would check those out first...

http://www.windowsitlibrary.com/Content/592/toc.html

 

[flotsam]

That was what I thought at first, but I can browse, edit, and save any file on the file server, so I don't think that is it.

Is there a limit to the quantity of files that forfiles can process?

 

[aquias]

Microsofts Forfiles Page (Not much new there)

http://www.microsoft.com/resources/...erv/2003/standard/proddocs/en-us/forfiles.asp

No where do I see anything listing a limit to the number of files this can process nor do I hit upon one myself with some testing.

I'm still leaning towards a permissions error of some kind. I would say begin to narrow down your search until you find out exactly where you're getting access denied and then reinitialize the NTFS permissions there. I have seen the problem where the folder didn't problem update its ACL and people with full admin rights were denied access.

Beyond that, I'm not supremely familiar with the forfiles command. But, from what I've tested and read your coding seems fine.

 

[flotsam]

Aquias,

Thanks for the post. I will look further into possible ACL issues.

Anyone else have a thought?

Chad

 

[bcastner]

My guess:

FindNextFile - unexpected return code=6 (on FindNext) line 317

What is happening on a file server is that the FindFirst handle used as the instance for FindNextFile faces the situation where the handle becomes invalid (error=6) because the file is deleted or modified by another network user.

 

[flotsam]

Bcastner,

That makes sense to me. I am guessing that also applies if I run this locally on the server, because if the file gets opened, or moved, or whatever, then forfiles does not have the capability to deal?

Thanks
Chad

 

[bcastner]

That is my guess, as the way in which it is enumerating folders is based on the logic to FindFirstFIle, save the handle, and then use that handle as the basis for a FindNextFile.

I know that error code = 6 indicates that the handle is invalid.

 

[aquias]

See, he's the smart one

 

[tsuji]

Hello all,

I'm doubtful of permission being an issue (else lot of commands will fail and rarely any users have every right to see every files on the box).

As to files being used/moved/deleted... maybe. But forfiles reporting should hardly touch physically the files... just a snapshot of entries? But I cannot be sure.

I would doubt the problem is from the memory handling and limitation.

I suggest, flotsam, you separate forfiles and sort in two separate steps. Run the forfiles and output to a file. Use the file and use the sort to produce a new sorted files. This way, you'll see clearly if the errors is from the forfiles reporting or from sort operation taking on piped data in the memory.

regards - tsuji

 

[flotsam]

I have a small update, and a question:

I found out that if I supply any subdirectory, as part of the directory argument in the forfiles command, it works perfectly fine. It just doesn't work when the root directory is supplied as the directory argument.

That being said, can anyone tell me how I can supply a list of variables (directory names) as the directory to scan? I can easily create a bare format list of directory names using:

dir /AD /B u:\ >c:\directory_list.txt

I just can't seem to figure out how to supply that list, as the directory variable.

Thank you all very much for your help.

 

[gpalmer711]

I have never used Forfiles myself but could it be your syntax? I'm guessing not due to your first line working, however...

In your original post you have /pU:\ without a space between p and U, however all the examples in

http://www.microsoft.com/resources/...erv/2003/standard/proddocs/en-us/forfiles.asp

show a space.



Greg Palmer
Freeware Utilities for Windows Administrators.

http://www.palmersoft.co.uk

 

[flotsam]

gplamer711,

Thanks for the info, I took a look at the link you provided, and apparently MS has their syntax incrrect. It does not work with a space, only without.

Thanks,
Chad

 

[gpalmer711]

Lol - now that does not surprise me

Greg Palmer
Freeware Utilities for Windows Administrators.

http://www.palmersoft.co.uk

 

[flotsam]

Yeah,

I kinda thought the same thing as well. It figures

Chad

 

[bcastner]

I thought about exactly this issue when looling at the Win32 library used for the forfiles calling sequence, but the examples of forfiles itself were fairly clear. I would ignore the errors, but I think they are valid syntax errors.

Go back above to my original thoughts of an invalid handle. Note the documentation on anything that scans the root directory, or uses a network share:

You cannot use root directories as the lpFileName input string for FindFirstFile, with or without a trailing backslash. To examine files in a root directory, use something like "C:\*" and step through the directory with FindNextFile. To get the attributes of a root directory, use GetFileAttributes. Prepending the string "\\?\" does not allow access to the root directory.

Similarly, on network shares, you can use an lpFileName of the form "\\server\service\*" but you cannot use an lpFileName that points to the share itself, such as "\\server\service".

To examine any directory other than a root directory, use an appropriate path to that directory, with no trailing backslash. For example, an argument of "C:\windows" will return information about the directory "C:\windows", not about any directory or file in "C:\windows". An attempt to open a search with a trailing backslash will always fail.

Be aware that someone could create or delete this file between the time you query for the result and the time you act upon the information. Therefore, if you are looking to create a file, it is best to use the CreateFile function with CREATE_NEW (fail if the file exists) or OPEN_EXISTING (fail if the file does not exist).

 

[bcastner]

Darn,
Source for the information on the Win32 library functions being used by forfiles:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/findfirstfile.asp

 

[tsuji]

flotsam wrote
>>I have the following:
>>forfiles -s -p[blue]y:\[/blue] -m*.* -d-365 -c"cmd /c echo @FDATE @FSIZE @PATH\@FILE" | sort /O C:\filereports\365daysold.txt
>>
>>[blue]The above runs perfectly as it is.[/blue]

Then as an update:
>>I have a small update, and a question:
>>
>>I found out that [blue]if I supply any subdirectory, as part of the directory argument in the forfiles command, it works perfectly fine. It just doesn't work when the root directory is supplied as the directory argument.[/blue]

It seems contraditory as to the assertion on the root directory taken as the argument for forfiles.

I continue to suspect that restricting the parent directory to a certain subdirectory of the root will make the dataset shrunk considerably => less memory intensive.

So I am not convinced. Maybe flotsam care to clarify - if you like, of course, that if doing the thing in two steps as I suggested it results in the same error?

- tsuji

 

[bcastner]

tsuji,

The documentation for "forfiles" shows root directory paths. But it also notes: "Forfiles works by implementing the recurse subdirectories flag on tools designed to process only a single file."

And consider the errors returned by the original poster of this thread:

FindNextFile - unexpected return code=6 (on FindNext) line 317
Warning : Access denied (during recursion) line 302
Warning : Access denied (on FindFirst) line 274

This suggests two possibilities I explored above:

. the handle for FindFirstFile becomes invalid with a recursion call to FindNextFile. This for a network file server would be commonplace;

. forfiles.exe, despite the documented examples, is going to throw an error on a root drive specification. That is my current guess, although I like both possibilities I discussed above. See my quoted passage two notes above. And the user experience. Just do not pass c:\ as an argument, pass c:\* or whatever share you wish.

Best Holiday wishes to you, tsuji.
You are just a remarkable member of this Forum.
Bill Castner

 

[tsuji]

Hi Bill,

I would go to look more carefully on what you'd quoted from the document. It sure has some bearing here.

My same wishes to you and to your family. I remain...

- tsuji