Determine File Ownership

I need VB6 code to determine file ownership of files that are on a network drive.

I have found plenty of code using advapi32.dll to get the file permissions and they work for local files.  However, they don't work for network drives.

I need some code to actually give me the file ownership for those that are on the network drives.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

This will do the trick, I just tested it and it works on my network, even over a VPN.
I forgot to mention that even though it says "...on Windows NT", this VB6 code works on my Win XP SP3 client with a Win2003 server.
adezoysa2Author Commented:
Tried this one already, comes up with a error 1332 when trying to use the LookupAccountSid routine.

The network share is not part of the domain i am currently in, although i have full control permissions.
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

Ahh, so that must be the issue.  I'm on my own domain and it worked perfectly, and I'm the domain admin.  Now that I think about it, I think you need domain admin permissions to see/access the ownership info.  Let's check this manually first.  Can you try bringing up the properties of an example file, select the security tab, and click the [Advanced] button.  Can you get this far?  Is so, can you select the "Owner" tab?  This will tell you if you can even do this in VB6 because VB6 will use your own credentials.  That may be the limiting factor.

I have access to another domain I can try.  Before I do, let me make sure I try to replicate what you are doing.

Can you confirm or correct my assumptions:
1. You are logged into domain A.  There exists a Domain B.
2. You have permissions to a certain network share on Domain B.  (We may need to know what permissions you have on this network share so I can try to duplicate.)
3. You have a drive mapped to a network share on Domain B.
4. You tried the previously named MS article targeting this mapped drive and it failed.

Can you specify the permissions you have on the intended example target folder or file?

Have you tried this on a file where you *do* have *administrative* permissions on the domain on which you are logged in?  This will confirm that the app you are using works.  After that, if it does not work, we will then know that the limitation is a security problem and can approach it differently.
adezoysa2Author Commented:
You're going through the same steps i have.  The first thing i tried was to look for the Owner of the file (from the OWNER's Tab).  this reads correctly shows as DOMAINB/USERNAME

that's what really puzzled me, if i can make windows explorer tell me the correct user, then why can't VB get the SID?

1. Yes logged into Domain A, and the network share is Domain B
2. I have FULL permissions to network share
3. Yes, have a mapped drive to a network share on DomainB
4. Yes i tried the MS code from the article targeting through the mapped drive and it failed.

My last resort is to run my application on Domain B machine directly, i've already tested and it works.

However, i would like to keep everything within Domain A if possible.

OK, I just tested the following scenario's with that MS VB6 app, all successfully.  I tested the following:

1) Logged into workstation on Domain A with Domain Admin User acct "DomainA\UserA", read file owner from network file share on Domain A - success.
2) Logged into workstation on Domain A with Domain Admin User (admin of both domains) acct "DomainA\UserA", read file owner from network file share on Domain B - success.
3) Logged into workstation on Domain A with Standard User acct "DomainA\UserA", read file owner from network file share on Domain A - success.
4) Logged into workstation on Domain A with Standard User acct "DomainA\UserA", read file owner from network file share on Domain B - success.

We must be missing something.  I still think it has to be permission related as to why it's not working for you.  If the program clearly works for you on your own domain, but not on the other domain, I think you should try a test like this:

Setup: Create a new standard (non-admin) user in Domain "A".  Then on Domain "B", create a new test share, with one file in it, with full permissions, and change the security on this test folder to grant this test user full permissions.  Log into a workstation in Domain "A", map a drive to the test share in Domain "B".  Verify that you can see the new drive and access it.  Manually open the properties of the one file in the test share and check the owner - it should allow you to do this.  If you can't get this far, you'll need to fix something here in this setup before running the test.

Running the test: Try the program again referencing the one file in the test share.  I modified the program to have a single Text1 field on it so I could easily test against different shares, and then I modified the code near the beginning of Command1_Click as follows:

   ' Obtain the path to the Windows Directory and use the notepad.exe file
   ' as it should be on the system.

'DISABLED   nLength = GetWindowsDirectory(szfilename, Len(szfilename))
'DISABLED   If nLength = 0 Then
'DISABLED     MsgBox "Unable to Obtain the Windows Directory"
'DISABLED   szfilename = Left$(szfilename, nLength) & "\notepad.exe"
    szfilename = Me!Text1

Open in new window

Try these things and let's see what happens.  I'd be surprised if you can manually open the properties and view the owner, but not through the program.
I should have added in the Setup section:

"Log into a workstation in Domain "A" as that new user, ..."

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
adezoysa2Author Commented:
Thank you for all of your help.  I am still having issues, but i believe that it is pointing towards the health of the DOMAIN B server.  Domain B is a Windows 2000 server, but the network share is NTFS.  should have worked, but .....

Thanks Again.
I have a win 2000 server I can test in a bit and let you know if the app works or not.  That may be the problem, and not crossing a domain or anything permission related.  I'll check and let you know shortly.
OK, I just tested the MS VB6 app against a Win2000 server share and it failed.  So that must be the issue.  It seems like there ought to be a solution because VB6 is of the same vintage as Win 2000 server.  I'll look some more.
adezoysa2Author Commented:
Hey, thanks for all your work!

Just another twist as well.  Remember when i said that if this didn't work, that i would just install my application on the Domain B server and run there.  Well, MSWinsock doesn't work natively on Windows 2000 Server.

back to the drawing board.
I'm not sure what I tested the other day that failed, because I can't reproduce the failure.  I have logged into an XP workstation as a regular user and I have been able to successfully use the VB6 app to get the file owner from a Windows 2000 server in my own domain, and a Windows 2003 file server in another domain.  The test user is not a domain admin in either domain.  They only have "Change" permissions on the test folder in the same domain to which the user is logged in, and read-only permission to the test folder in the other domain, which they are not a member.  They only have access to the share in the other domain by explicit granting access to the share across the domain trust.

But I do have another test for you to try.  Just to check this, try putting the following batch file on your local computer and run it with a parameter referencing the test file for which you can try to get the owner property.  For instance, if you name it "FileOwner.bat", try "FileOwner Y:\TestFolder\TestFile.txt" (or whatever your test files is).  Let me know if that returns on the next line the actual owner of the file.

@echo off

set File=%1
if not exist "%File%" GOTO Syntax

rem	*Breaing down the following command for documentation:
rem	*
rem	*FOR /F "skip=5 tokens=5 delims= " %%A IN (...) DO ...
rem	* This loops through the output from the command in the parenthesis
rem	* looking for the 5th column and assigns it to %A variable.
rem	* Remember: in a batch file FOR command, the variable 
rem	* is %a, but because it is in a FOR command, it has to have
rem	* an extra % symbol in front of it.  At a DOS prompt, you
rem	* would just use a single % symbol.
rem	*
rem	*DIR/A-D/Q "%File%"
rem 	* This uses the DIR command matching the filespec "%File%",
rem	* along with the following qualifiers:
rem	* The portion "/A-D" indicates to include files with the
rem	* "A"ttributes specified.  In this case, "-D" means to 
rem	* exclude directories.  
rem	* /Q means to show the file owner.
rem	* So list files showing the owner, excluding directories,
rem	* that match the filespec "%File%", which is a DOS variable.
rem 	*
rem 	*FIND /V "(s)"
rem 	* This searches the reuslts passed to it and excludes lines that 
rem 	* have the text "(s)" in them, essentially the last two summary 
rem	* lines of byte counts in a typical DIR command output.
rem 	*
rem	*DO @ECHO %%A
rem	* The outputs the results.
rem	* Remember, we're still in the FOR command, so we have to
rem	* use double % symbols.  At the command promtp directly, you 
rem	* would not use two % symbols.
rem 	*
FOR /F "skip=5 tokens=5 delims= " %%A IN ('DIR/A-D/Q "%File%" ^| FIND /V "(s)"') DO @ECHO %%A

goto End

echo You must supply a valid file (including path if necessary) as the first parameter.


Open in new window

If this wokrs for you, maybe we can shell out of VB6 to execute this statement and get the owner info that you need.
adezoysa2Author Commented:
the response comes back as ... for those files that are non-admin.  for those files owned by administrators it comes back as BUITLIN\Administrator
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.