[archive] C$Copy Question

Dominique Sacre
Author
Rocketeer
Forum|Forum|17 years ago
July 31, 2008

[Migrated content. Thread originally posted on 30 July 2008]

Hello,

I am having an issue with the C$Copy command and I am wondering if anybody has any solutions for me. When I use UNC Pathing in my copy statement I get a status code of 1 returned when a "$" is present but at all other times it appears to work. For example

Source-file = "\\\\dell4\\c$\\program\\checks1.txt"
Dest-file = "\\\\dell4\\c$\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

this returns a status-code of 1 and the file does not copy.

However it I use the following example

Source-file = "\\\\dell4\\cdrive\\program\\checks1.txt"
Dest-file = "\\\\dell4\\cdrive\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

The copy command works fine.

We have a client who has some wild network setup going on and they will not setup mapped drives and will not change the share that we are able to use.:mad:

We are on the 7.0 version of the runtime and compiler.

Thanks for your help

Scott Meiners

The driveletter$ shares is a part of a group of shares in Windows known as Administrative shares or Hidden shares.
These shares are automatically created by the OS, and if you delete them, they will reappear at the next logon.

These shares are there for Windows to be able to conduct services and are thus intended for a special group of users. The driveletter$ shares in particular are for Administrators, Backup Agents and Domain controllers group exclusively.

I suppose the reason this fail for your user is because the current user is not a member of one of those groups.
As these shares are designated special tasks, nor can you change the access permissions on them.

In short, these shares are not for common use.

So, if the customer don't want to create designated shares for their application, their only solution is to add the user(s) account to for instance the Administrators group. I for one, would consider that a worse idea than adding another share.

Like

D

Dominique Sacre
Author
Rocketeer
Forum|Forum|17 years ago
July 31, 2008

[Migrated content. Thread originally posted on 30 July 2008]

Hello,

I am having an issue with the C$Copy command and I am wondering if anybody has any solutions for me. When I use UNC Pathing in my copy statement I get a status code of 1 returned when a "$" is present but at all other times it appears to work. For example

Source-file = "\\\\dell4\\c$\\program\\checks1.txt"
Dest-file = "\\\\dell4\\c$\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

this returns a status-code of 1 and the file does not copy.

However it I use the following example

Source-file = "\\\\dell4\\cdrive\\program\\checks1.txt"
Dest-file = "\\\\dell4\\cdrive\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

The copy command works fine.

We have a client who has some wild network setup going on and they will not setup mapped drives and will not change the share that we are able to use.:mad:

We are on the 7.0 version of the runtime and compiler.

Thanks for your help

Scott Meiners

The driveletter$ shares is a part of a group of shares in Windows known as Administrative shares or Hidden shares.
These shares are automatically created by the OS, and if you delete them, they will reappear at the next logon.

These shares are there for Windows to be able to conduct services and are thus intended for a special group of users. The driveletter$ shares in particular are for Administrators, Backup Agents and Domain controllers group exclusively.

I suppose the reason this fail for your user is because the current user is not a member of one of those groups.
As these shares are designated special tasks, nor can you change the access permissions on them.

In short, these shares are not for common use.

So, if the customer don't want to create designated shares for their application, their only solution is to add the user(s) account to for instance the Administrators group. I for one, would consider that a worse idea than adding another share.

Like

D

Dominique Sacre
Author
Rocketeer
Forum|Forum|17 years ago
August 4, 2008

[Migrated content. Thread originally posted on 30 July 2008]

Hello,

I am having an issue with the C$Copy command and I am wondering if anybody has any solutions for me. When I use UNC Pathing in my copy statement I get a status code of 1 returned when a "$" is present but at all other times it appears to work. For example

Source-file = "\\\\dell4\\c$\\program\\checks1.txt"
Dest-file = "\\\\dell4\\c$\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

this returns a status-code of 1 and the file does not copy.

However it I use the following example

Source-file = "\\\\dell4\\cdrive\\program\\checks1.txt"
Dest-file = "\\\\dell4\\cdrive\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

The copy command works fine.

We have a client who has some wild network setup going on and they will not setup mapped drives and will not change the share that we are able to use.:mad:

We are on the 7.0 version of the runtime and compiler.

Thanks for your help

Scott Meiners

whats about to map the share before the copy and delete it after the copy?

for example:

call "C$SYSTEM" using
"net use X: \\\\dell4\\c$\\ password /user:username /persistent:no", 96
giving exit status
end-call.

evaluate exit-status
when 0 move "LW mapped" to err-msg
when 2 move "LW was mapped" to err-msg
when other move "unknown status" to err-msg
end-evaluate.

Source-file = "x:\\program\\checks1.txt"
Dest-file = "x:\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

call "C$SYSTEM" using
"net use x: /delete", 96
giving exit status
end-call.

Like

D

Dominique Sacre
Author
Rocketeer
Forum|Forum|17 years ago
August 5, 2008

[Migrated content. Thread originally posted on 30 July 2008]

Hello,

I am having an issue with the C$Copy command and I am wondering if anybody has any solutions for me. When I use UNC Pathing in my copy statement I get a status code of 1 returned when a "$" is present but at all other times it appears to work. For example

Source-file = "\\\\dell4\\c$\\program\\checks1.txt"
Dest-file = "\\\\dell4\\c$\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

this returns a status-code of 1 and the file does not copy.

However it I use the following example

Source-file = "\\\\dell4\\cdrive\\program\\checks1.txt"
Dest-file = "\\\\dell4\\cdrive\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

The copy command works fine.

We have a client who has some wild network setup going on and they will not setup mapped drives and will not change the share that we are able to use.:mad:

We are on the 7.0 version of the runtime and compiler.

Thanks for your help

Scott Meiners

This is certainly an alternative. But then you will have to feed this routine with the username and password of a member of one of the above mentioned groups.
I don't think that is going to be any more secure than creating a designated share...

Like

D

Dominique Sacre
Author
Rocketeer
Forum|Forum|17 years ago
August 7, 2008

[Migrated content. Thread originally posted on 30 July 2008]

Hello,

I am having an issue with the C$Copy command and I am wondering if anybody has any solutions for me. When I use UNC Pathing in my copy statement I get a status code of 1 returned when a "$" is present but at all other times it appears to work. For example

Source-file = "\\\\dell4\\c$\\program\\checks1.txt"
Dest-file = "\\\\dell4\\c$\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

this returns a status-code of 1 and the file does not copy.

However it I use the following example

Source-file = "\\\\dell4\\cdrive\\program\\checks1.txt"
Dest-file = "\\\\dell4\\cdrive\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

The copy command works fine.

We have a client who has some wild network setup going on and they will not setup mapped drives and will not change the share that we are able to use.:mad:

We are on the 7.0 version of the runtime and compiler.

Thanks for your help

Scott Meiners

Thanks for all of your suggestions. However, after digging through the problem, I found that I had a different issue where the data file was not actually where I thought it was:o. After I fixed that problem, the c$Copy work wonderfully.

Thanks again,

Scott

Like

D

Dominique Sacre
Author
Rocketeer
Forum|Forum|17 years ago
August 7, 2008

[Migrated content. Thread originally posted on 30 July 2008]

Hello,

I am having an issue with the C$Copy command and I am wondering if anybody has any solutions for me. When I use UNC Pathing in my copy statement I get a status code of 1 returned when a "$" is present but at all other times it appears to work. For example

Source-file = "\\\\dell4\\c$\\program\\checks1.txt"
Dest-file = "\\\\dell4\\c$\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

this returns a status-code of 1 and the file does not copy.

However it I use the following example

Source-file = "\\\\dell4\\cdrive\\program\\checks1.txt"
Dest-file = "\\\\dell4\\cdrive\\program\\save\\checks120080730.txt"

CALL "C$COPY" USING SOURCE-FILE DEST-FILE GIVING STATUS-CODE

The copy command works fine.

We have a client who has some wild network setup going on and they will not setup mapped drives and will not change the share that we are able to use.:mad:

We are on the 7.0 version of the runtime and compiler.

Thanks for your help

Scott Meiners

Thanks for all of your suggestions. However, after digging through the problem, I found that I had a different issue where the data file was not actually where I thought it was:o. After I fixed that problem, the c$Copy work wonderfully.

Thanks again,

Scott