We run a simple exe file at work to move files from one network drive to another
(its a case where we don’t want users to directly access the destination folder, so there is a small program that moves the files)
so that program does the required moving of files om my computer under any domain login, but it doesn’t run under any domain login on a user’s PC
so clearly, its a PC problem rather than folder permissions or any sort of account permissions. I have installed VB runtimesand have also installed .NET framework on the user’s PC but still it gives this error when we instruct the program to move files.
[thumb=H]error8603_6953657.JPG[/thumb]
[including full screenshot to give u an idea abt the program]
J:\ Drive has folders where those files need to go … The thing that baffles me is that i can go to User’s PC … log in with his username and move the file manually from the source to destination problem… but i get runtime error 70 when i try to move files with the program..
Couple of quick questions...what credentials are used to map the drive to J:. Do those credentials have permissions to move files. A good test will be to log in as that user/service that is used to map the drive and try moving the files and see what happens.
mapping the J drive thru the user's credentials...
this user is in a group called "PDF movers" has permissions to the destination directory. To verify that, i have moved a file manually ... also created a new folder in the destination directory to check the permissions there.
i just tried to create a new folder in the source directory and also deleted a file to check the permissions there as well... both operations were successful..its just that the program doesn't recognize the permissions ...
in the screenshot, u can see that there is a rename option,, when i try to rename a file from that user's pc with his credentials , its gives the same error 70 ... But when i try to rename the file using his credentials from my PC, it works..
-stand alone exe
-the user has permissions to source drive – i deleted/moved/created files in the source dir. to verify.
-domain is same- i took it out of domain and then re added it.
-Yes…
hey, how can i tell if its a dcom app ?
its only 48k in size, its not in program files directory... i can copy that 48KB file and run it from my desktop...
i just tried this one thing and the program was able to move that file under his credentials..
i opened the application... clicked on the file [when i click on files in source directory, it previews in the top pane of the program.. therefore initiates the adobe process (AcroRd32.exe) ]
so i killed the AcroRd32 process and then tried moving files through program and it didn't give runtime error 70... so the problem is with adobe on that PC rather than the network permissions
any idea how to get around that ... come to think of it... i m wondering how my pc moves the file while i can see the preview and the adobe process is running...
if you are instantiating a COM component from withint your app that exists on another machine on the network, that makes that component a distrubuted component. You will need to use DCOMCNFG.EXE to properly set the security and credentials for the processes and domain users that can access the component.
It is the permission issue not due to lack of credentials though but because the file is locked while its being previewed by adobe reader.
Is it possible for you to tell me how you are copying the file? Are you using FileCopy or are you using a File System Object? I am assuming ur dev env is VB
Asif,
yes , its in VB... we used File System Object
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.GetFile(SelectedFile.Text)
u were absolutely rite.. it wasn't due to lack of credentials.. it was the file lock
here is what i did to fix it...
i uninstalled all versions of adobe
-deleted registry folders of Adobe both places .. HKEY_CURRENT_USER & HKEY_LOCAL_MACHINE ]
-restarted the comp
-Installed Adobe once again...
and BOOM -- back in business.. The files are moving from source to destination :):):)
well, I wonder if it was locking the file because you were using fso.getfile (and then copy it) instead of directly using fso.copyfile by specifying the source and the destination.