File move fails with a "You Must Have permissions"

This used to work and now it doesn't - why has me completely baffled.

3 Servers

Server A - Windows 2003, Server B - Windows 2003 Web, and Server C - Windows
2008
Server C is a Jobs and FTP server - It moves files around both internal and
external.

Server A is a DB server, Server B is an Application server. A job is setup
on Server C using "Automate" that detect activity in the Server A\Send2B
folder. It then scans the Server B\in folder for a file of the same name
and deletes it (the files are always named the same) if it exists. Finally,
it grabs the new file from Server A and sends it to the Server B\in folder.
The job fails either with no file deleted (Step 2) or no file copied (Step
5). To troubleshoot the issue, I log into Server C as a Domain Admin and
attempt to move the file manually - that is when I get the error in the
subject line. I check the permissions on the destination folder -
Administrator's "Full Control". So I create another folder on Server B,
share it and try to move the file there - it works with no problem. I
figure something is wrong with the in folder so I delete it and recreate it.
Now the folder is new and is empty so I attempt to move the file logged into
Server C from the share on Server A to Server B. It fails again. But
wait - it gets better... If I rename the source file on Server A I can move
it no problem to Server B. I am completely at a loss as to why this is
happening. Another symptom that may be related. When logged into Server C
I can delete the file from the Server B\in folder (or at least it dissapears
from the folder). But the file is not actually deleted. If I log into
Server B I can see that the file is still in the "in" folder. I can delete
it locally no problem, but even when I delete it locally, I still cannot
copy the new file from Server A to Server B using Server C.

AARG!

 

"Steve65" <sjha@preferredcredit.com> wrote in message
news:eUCx28uMKHA.5072@TK2MSFTNGP05.phx.gbl...<!--coloro:blue--><span style="color:blue <!--/coloro-->
> This used to work and now it doesn't - why has me completely baffled.
>
> 3 Servers
>
> Server A - Windows 2003, Server B - Windows 2003 Web, and Server C -
> Windows 2008
> Server C is a Jobs and FTP server - It moves files around both internal
> and external.
>
> Server A is a DB server, Server B is an Application server. A job is
> setup on Server C using "Automate" that detect activity in the Server
> ASend2B folder. It then scans the Server Bin folder for a file of the
> same name and deletes it (the files are always named the same) if it
> exists. Finally, it grabs the new file from Server A and sends it to the
> Server Bin folder. The job fails either with no file deleted (Step 2) or
> no file copied (Step 5). To troubleshoot the issue, I log into Server C
> as a Domain Admin and attempt to move the file manually - that is when I
> get the error in the subject line. I check the permissions on the
> destination folder - Administrator's "Full Control". So I create another
> folder on Server B, share it and try to move the file there - it works
> with no problem. I figure something is wrong with the in folder so I
> delete it and recreate it. Now the folder is new and is empty so I attempt
> to move the file logged into Server C from the share on Server A to Server
> B. It fails again. But wait - it gets better... If I rename the source
> file on Server A I can move it no problem to Server B. I am completely at
> a loss as to why this is happening. Another symptom that may be related.
> When logged into Server C I can delete the file from the Server Bin
> folder (or at least it dissapears from the folder). But the file is not
> actually deleted. If I log into Server B I can see that the file is still
> in the "in" folder. I can delete it locally no problem, but even when I
> delete it locally, I still cannot copy the new file from Server A to
> Server B using Server C.
>
> AARG!<!--colorc--><!--/colorc-->

The file might be locked at the source or target machine. Oh.exe (Open
Handles) would probably tell you:
oh.exe | find /i "filename.txt"
You will have to reboot your servers after installing oh.exe. You can get it
from here:
.

 

I cannot reboot the server during the day, but the symptoms do not strike me
as a file lock anyway. Reason being, I can delete, rename, do whatever I
want to the file when logged on locally. It is only when trying to access
from another machine that I have the issues - doesn't that rule out a file
lock?

Thanks
Steve
"Pegasus [MVP]" <news@microsoft.com> wrote in message
news:ezvYrxvMKHA.3192@TK2MSFTNGP05.phx.gbl...<!--coloro:blue--><span style="color:blue <!--/coloro-->
>
> "Steve65" <sjha@preferredcredit.com> wrote in message
> news:eUCx28uMKHA.5072@TK2MSFTNGP05.phx.gbl...<!--coloro:green--><span style="color:green <!--/coloro-->
>> This used to work and now it doesn't - why has me completely baffled.
>>
>> 3 Servers
>>
>> Server A - Windows 2003, Server B - Windows 2003 Web, and Server C -
>> Windows 2008
>> Server C is a Jobs and FTP server - It moves files around both internal
>> and external.
>>
>> Server A is a DB server, Server B is an Application server. A job is
>> setup on Server C using "Automate" that detect activity in the Server
>> ASend2B folder. It then scans the Server Bin folder for a file of the
>> same name and deletes it (the files are always named the same) if it
>> exists. Finally, it grabs the new file from Server A and sends it to the
>> Server Bin folder. The job fails either with no file deleted (Step 2) or
>> no file copied (Step 5). To troubleshoot the issue, I log into Server C
>> as a Domain Admin and attempt to move the file manually - that is when I
>> get the error in the subject line. I check the permissions on the
>> destination folder - Administrator's "Full Control". So I create another
>> folder on Server B, share it and try to move the file there - it works
>> with no problem. I figure something is wrong with the in folder so I
>> delete it and recreate it. Now the folder is new and is empty so I
>> attempt to move the file logged into Server C from the share on Server A
>> to Server B. It fails again. But wait - it gets better... If I rename
>> the source file on Server A I can move it no problem to Server B. I am
>> completely at a loss as to why this is happening. Another symptom that
>> may be related. When logged into Server C I can delete the file from the
>> Server Bin folder (or at least it dissapears from the folder). But the
>> file is not actually deleted. If I log into Server B I can see that the
>> file is still in the "in" folder. I can delete it locally no problem,
>> but even when I delete it locally, I still cannot copy the new file from
>> Server A to Server B using Server C.
>>
>> AARG!<!--colorc--><!--/colorc-->
>
> The file might be locked at the source or target machine. Oh.exe (Open
> Handles) would probably tell you:
> oh.exe | find /i "filename.txt"
> You will have to reboot your servers after installing oh.exe. You can get
> it from here:
> .
> <!--colorc--><!--/colorc-->

 

The symptomps you report sound rather contradictory. I wonder if there is
some typographical error behind the whole thing. To ensure a tightly
controlled environment, I suggest you create the batch file below, then do
this:
1. Set lines 2 and 3 to suit your environment.
2. Set line 4 for a "good" file name.
3. Run the batch file, then examine c:\test.txt. There should be no error
message.
4. Set line 4 for the "bad" file name.
5. Run the batch file, then paste the contents of c:\test.txt into your
response.

@echo off
set ServerAFolder=\\ServerA\ShareA\FolderA
set ServerBFolder=\\ServerB\ShareB\FolderB
set SourceFile=xxx.txt
if not exist "%ServerAFolder%\%SourceFile%" (
echo File "%ServerAFolder%\%SourceFile%" not found.
goto :eof
)
if exist "%ServerBFolder%\%SourceFile%" (
echo File "%ServerBFolder%\%SourceFile%" already exists.
goto :eof
)
calcs "%ServerAFolder%" 1>c:\test.txt 2>&1
calcs "%ServerBFolder%" 1>>c:\test.txt 2>>&1
xcopy /y "%ServerAFolder%\%SourceFile%" c:\ 1>>c:\test.txt 2>>&1
xcopy /y %comspec% "%ServerBFolder%\%SourceFile%" c:\ 1>>c:\test.txt 2>>&1
xcopy /y "%ServerAFolder%\%SourceFile%" "%ServerBFolder%\" 1>>c:\test.txt
2>>&1
[The last three lines are long lines. They start with "xcopy" and ends with
"&1"]

"Steve65" <sjha@preferredcredit.com> wrote in message
news:ehW0KwxMKHA.5108@TK2MSFTNGP02.phx.gbl...<!--coloro:blue--><span style="color:blue <!--/coloro-->
>I cannot reboot the server during the day, but the symptoms do not strike
>me as a file lock anyway. Reason being, I can delete, rename, do whatever
>I want to the file when logged on locally. It is only when trying to
>access from another machine that I have the issues - doesn't that rule out
>a file lock?
>
> Thanks
> Steve
> "Pegasus [MVP]" <news@microsoft.com> wrote in message
> news:ezvYrxvMKHA.3192@TK2MSFTNGP05.phx.gbl...<!--coloro:green--><span style="color:green <!--/coloro-->
>>
>> "Steve65" <sjha@preferredcredit.com> wrote in message
>> news:eUCx28uMKHA.5072@TK2MSFTNGP05.phx.gbl...<!--coloro:darkred--><span style="color:darkred <!--/coloro-->
>>> This used to work and now it doesn't - why has me completely baffled.
>>>
>>> 3 Servers
>>>
>>> Server A - Windows 2003, Server B - Windows 2003 Web, and Server C -
>>> Windows 2008
>>> Server C is a Jobs and FTP server - It moves files around both internal
>>> and external.
>>>
>>> Server A is a DB server, Server B is an Application server. A job is
>>> setup on Server C using "Automate" that detect activity in the Server
>>> ASend2B folder. It then scans the Server Bin folder for a file of the
>>> same name and deletes it (the files are always named the same) if it
>>> exists. Finally, it grabs the new file from Server A and sends it to
>>> the Server Bin folder. The job fails either with no file deleted (Step
>>> 2) or no file copied (Step 5). To troubleshoot the issue, I log into
>>> Server C as a Domain Admin and attempt to move the file manually - that
>>> is when I get the error in the subject line. I check the permissions on
>>> the destination folder - Administrator's "Full Control". So I create
>>> another folder on Server B, share it and try to move the file there - it
>>> works with no problem. I figure something is wrong with the in folder
>>> so I delete it and recreate it. Now the folder is new and is empty so I
>>> attempt to move the file logged into Server C from the share on Server A
>>> to Server B. It fails again. But wait - it gets better... If I rename
>>> the source file on Server A I can move it no problem to Server B. I am
>>> completely at a loss as to why this is happening. Another symptom that
>>> may be related. When logged into Server C I can delete the file from the
>>> Server Bin folder (or at least it dissapears from the folder). But the
>>> file is not actually deleted. If I log into Server B I can see that the
>>> file is still in the "in" folder. I can delete it locally no problem,
>>> but even when I delete it locally, I still cannot copy the new file from
>>> Server A to Server B using Server C.
>>>
>>> AARG!<!--colorc--><!--/colorc-->
>>
>> The file might be locked at the source or target machine. Oh.exe (Open
>> Handles) would probably tell you:
>> oh.exe | find /i "filename.txt"
>> You will have to reboot your servers after installing oh.exe. You can get
>> it from here:
>> .
>><!--colorc--><!--/colorc-->
> <!--colorc--><!--/colorc-->

 

I'll get back with the results.

Thanks for your help
Steve

"Pegasus [MVP]" <news@microsoft.com> wrote in message
news:Ooe$uj4MKHA.220@TK2MSFTNGP02.phx.gbl...<!--coloro:blue--><span style="color:blue <!--/coloro-->
> The symptomps you report sound rather contradictory. I wonder if there is
> some typographical error behind the whole thing. To ensure a tightly
> controlled environment, I suggest you create the batch file below, then do
> this:
> 1. Set lines 2 and 3 to suit your environment.
> 2. Set line 4 for a "good" file name.
> 3. Run the batch file, then examine c:test.txt. There should be no error
> message.
> 4. Set line 4 for the "bad" file name.
> 5. Run the batch file, then paste the contents of c:test.txt into your
> response.
>
> @echo off
> set ServerAFolder=\ServerAShareAFolderA
> set ServerBFolder=\ServerBShareBFolderB
> set SourceFile=xxx.txt
> if not exist "%ServerAFolder%%SourceFile%" (
> echo File "%ServerAFolder%%SourceFile%" not found.
> goto :eof
> )
> if exist "%ServerBFolder%%SourceFile%" (
> echo File "%ServerBFolder%%SourceFile%" already exists.
> goto :eof
> )
> calcs "%ServerAFolder%" 1>c:test.txt 2>&1
> calcs "%ServerBFolder%" 1>>c:test.txt 2>>&1
> xcopy /y "%ServerAFolder%%SourceFile%" c: 1>>c:test.txt 2>>&1
> xcopy /y %comspec% "%ServerBFolder%%SourceFile%" c: 1>>c:test.txt 2>>&1
> xcopy /y "%ServerAFolder%%SourceFile%" "%ServerBFolder%" 1>>c:test.txt
> 2>>&1
> [The last three lines are long lines. They start with "xcopy" and ends
> with "&1"]
>
> "Steve65" <sjha@preferredcredit.com> wrote in message
> news:ehW0KwxMKHA.5108@TK2MSFTNGP02.phx.gbl...<!--coloro:green--><span style="color:green <!--/coloro-->
>>I cannot reboot the server during the day, but the symptoms do not strike
>>me as a file lock anyway. Reason being, I can delete, rename, do whatever
>>I want to the file when logged on locally. It is only when trying to
>>access from another machine that I have the issues - doesn't that rule out
>>a file lock?
>>
>> Thanks
>> Steve
>> "Pegasus [MVP]" <news@microsoft.com> wrote in message
>> news:ezvYrxvMKHA.3192@TK2MSFTNGP05.phx.gbl...<!--coloro:darkred--><span style="color:darkred <!--/coloro-->
>>>
>>> "Steve65" <sjha@preferredcredit.com> wrote in message
>>> news:eUCx28uMKHA.5072@TK2MSFTNGP05.phx.gbl...
>>>> This used to work and now it doesn't - why has me completely baffled.
>>>>
>>>> 3 Servers
>>>>
>>>> Server A - Windows 2003, Server B - Windows 2003 Web, and Server C -
>>>> Windows 2008
>>>> Server C is a Jobs and FTP server - It moves files around both internal
>>>> and external.
>>>>
>>>> Server A is a DB server, Server B is an Application server. A job is
>>>> setup on Server C using "Automate" that detect activity in the Server
>>>> ASend2B folder. It then scans the Server Bin folder for a file of
>>>> the same name and deletes it (the files are always named the same) if
>>>> it exists. Finally, it grabs the new file from Server A and sends it
>>>> to the Server Bin folder. The job fails either with no file deleted
>>>> (Step 2) or no file copied (Step 5). To troubleshoot the issue, I log
>>>> into Server C as a Domain Admin and attempt to move the file manually -
>>>> that is when I get the error in the subject line. I check the
>>>> permissions on the destination folder - Administrator's "Full Control".
>>>> So I create another folder on Server B, share it and try to move the
>>>> file there - it works with no problem. I figure something is wrong
>>>> with the in folder so I delete it and recreate it. Now the folder is
>>>> new and is empty so I attempt to move the file logged into Server C
>>>> from the share on Server A to Server B. It fails again. But wait - it
>>>> gets better... If I rename the source file on Server A I can move it
>>>> no problem to Server B. I am completely at a loss as to why this is
>>>> happening. Another symptom that may be related. When logged into
>>>> Server C I can delete the file from the Server Bin folder (or at least
>>>> it dissapears from the folder). But the file is not actually deleted.
>>>> If I log into Server B I can see that the file is still in the "in"
>>>> folder. I can delete it locally no problem, but even when I delete it
>>>> locally, I still cannot copy the new file from Server A to Server B
>>>> using Server C.
>>>>
>>>> AARG!
>>>
>>> The file might be locked at the source or target machine. Oh.exe (Open
>>> Handles) would probably tell you:
>>> oh.exe | find /i "filename.txt"
>>> You will have to reboot your servers after installing oh.exe. You can
>>> get it from here:
>>> .
>>><!--colorc--><!--/colorc-->
>><!--colorc--><!--/colorc-->
>
> <!--colorc--><!--/colorc-->