OT: Windows.CopyFile() and citrix

Just want to run this past the NG in case someone has experience of
this or any insight..

Long standing application that copies files from a CD into a
destination folder. It also renames files that don't meet with a
certain naming convention. Has been working perfectly for a few years.

My customer now runs this application on citrix over a 100MB leased
line to Amsterdam. As I predicted, this has introduced a number of
issues (I hate citrix!). This latest one has me more than a little
puzzled, here's a fragment (slightly simplified for ease of reading) of
code:

if CopyFile(PAnsiChar(aFileName), PAnsiChar(sDest), true) then
begin
if FileGetAttr(sDest) <> 32 then //32 = hex 20 = Archive only
FileSetAttr(sDest,32);
memGood.Lines.Add(format('copied file: %s to %s', [aFileName,
sDest]));
end else
begin
iError := GetLastError;
sError := SysErrorMessage(iError);
memBad.Lines.Add(format('unable to copy file: %s to %s (%s)',
[aFileName, sDest, sError]));
end;

For a random number of files on each CD, memBad ends up with a bunch of
lines like this:

unable to copy file: U:\MSN 26992 D-ABUC Condor Docs
(1)\3_Data-Maintenance\3.11_Workpackage\Year-2009\10_OCT\BUC-121009-01.p
df to \\AD11\FORTRESS$\STREAM\26992\2012-06_CD\2\MSN 26992 D-ABUC
Condor Docs
(1)\3_Data-Maintenance\3.11_Workpackage\Year-2009\10_OCT\BUC-121009-01.p
df (The operation completed successfully)

So CopyFile returns false but the 'error' is "The operation completed
successfully". WTF?

If you're wondering why a CD would be in the U:\ drive, citrix does
this strange mapping of drives and in this case the CD drive ends up as
U:\

All I can think of is to 'hand-roll' a FileCopy function using two
TFileStreams in the hope that, even if it's no more successful, I might
at least get a meaningful message if it fails.

Anybody have any thoughts or suggestions?

Cheers
Dave

Hi,

CopyFile(..., ..., True) return False if the destination file already
exists (I do not remember how GetLastError is positioned in this case).
Is it your case ?

Other idea: did you try with SHFileOperation() to copy the files ?


Michaël

Le 03/07/2012 17:37, Dave Sellers a écrit :
> Just want to run this past the NG in case someone has experience of
> this or any insight..
>
> Long standing application that copies files from a CD into a
> destination folder. It also renames files that don't meet with a
> certain naming convention. Has been working perfectly for a few years.
>
> My customer now runs this application on citrix over a 100MB leased
> line to Amsterdam. As I predicted, this has introduced a number of
> issues (I hate citrix!). This latest one has me more than a little
> puzzled, here's a fragment (slightly simplified for ease of reading) of
> code:
>
> if CopyFile(PAnsiChar(aFileName), PAnsiChar(sDest), true) then
> begin
> if FileGetAttr(sDest)<> 32 then //32 = hex 20 = Archive only
> FileSetAttr(sDest,32);
> memGood.Lines.Add(format('copied file: %s to %s', [aFileName,
> sDest]));
> end else
> begin
> iError := GetLastError;
> sError := SysErrorMessage(iError);
> memBad.Lines.Add(format('unable to copy file: %s to %s (%s)',
> [aFileName, sDest, sError]));
> end;
>
> For a random number of files on each CD, memBad ends up with a bunch of
> lines like this:
>
> unable to copy file: U:\MSN 26992 D-ABUC Condor Docs
> (1)\3_Data-Maintenance\3.11_Workpackage\Year-2009\10_OCT\BUC-121009-01.p
> df to \\AD11\FORTRESS$\STREAM\26992\2012-06_CD\2\MSN 26992 D-ABUC
> Condor Docs
> (1)\3_Data-Maintenance\3.11_Workpackage\Year-2009\10_OCT\BUC-121009-01.p
> df (The operation completed successfully)
>
> So CopyFile returns false but the 'error' is "The operation completed
> successfully". WTF?
>
> If you're wondering why a CD would be in the U:\ drive, citrix does
> this strange mapping of drives and in this case the CD drive ends up as
> U:\
>
> All I can think of is to 'hand-roll' a FileCopy function using two
> TFileStreams in the hope that, even if it's no more successful, I might
> at least get a meaningful message if it fails.
>
> Anybody have any thoughts or suggestions?
>
> Cheers
> Dave

Hi Michaël

> Hi,
>
> CopyFile(..., ..., True) return False if the destination file already
> exists (I do not remember how GetLastError is positioned in this
> case). Is it your case ?

Sadly not, the destination files do not exist.

>
> Other idea: did you try with SHFileOperation() to copy the files ?

That's an idea, I'll give that a try, thanks for the suggestion.

Dave

Op 3-7-2012 17:37, Dave Sellers schreef:

Hi Dave,
this is a difficult one.

pity that the value of getlasterror is not shown.

questions :

what compiler ?
unicode ?
are the files copied or not ?
can explorer.exe do it ?

some remarks :


the path is long (>=143 characters)
if \\ad11\fortress$ translates to a string of more than 117 characters
then the complete string is larger than _MAX_PATH (the solution is to
prefix with \\.\ in that case the complete path cannot exceed 32k - 1.

I found some reports for copyfile having trouble with readonly files
(your files are on CD)


Ad Franse

Hi Ad Franse,

My responses embedded below:

> pity that the value of getlasterror is not shown.

Do you mean the integer value instead of the string returned by
SysErrorMessage() ?

>
> questions :
>
> what compiler ?

Delphi 7

> unicode ?

I'm using string not widestring. Hmm, could it be that the filename
contains unicode characters and that by the time it reaches CopyFile it
is nonsense...?

> are the files copied or not ?

Not.

> can explorer.exe do it ?

Will report back on that.
>
> the path is long (>=143 characters)
> if \\ad11\fortress$ translates to a string of more than 117 characters
> then the complete string is larger than _MAX_PATH (the solution is to
> prefix with \\.\ in that case the complete path cannot exceed 32k - 1.

Good point, I'm checking the full path of that share. Having said
that, I have had issues in the path where users, frustrated by the path
limitations, found a workaround by sharing a folder a good way down the
path and then mapping a drive to it. This caused other code to fail
where I was trying to copy *from* such a location have expanded to a
full UNC path that was then > _MAX_PATH.

I have also experimented with prefixes (\\?\ and \\UNC\) but my
/recollection/ was that some functions (e.g. CopyFile) didn't like the
prefixes.

>
> I found some reports for copyfile having trouble with readonly files
> (your files are on CD)

Indeed mine are on CD. In fact since my original post, I had the user
copy the CD to a folder on the server and to run the import function
from there and all worked fine which, as I write this sentence,
suggests that the output path length is not the issue...

Will report back more when available.

Cheers
Dave

Dave,

FWIW,

I've encountered the same problems with both Citrix sessions and Remote
Desktop sessions,(MS forced Citrix to create this feature and build it
into the MS Server OS's starting in 1997).

I've also encountered similar problems recently when implementing code
that uses the clipboard.

File and clipboard operations sometimes become victims of the least bit
of latency on thin client sessions. The differences can be very subtle
as I have found that a file copy operation will work properly one time
and not a second time from a wireless laptop running a remote
desktop...then I'll disconnect the session, reconnect to the same
session from a wired desktop and have it run fine...Then go back to the
original laptop, connect it via cable and voila it works also.

So, I guess the point of my dribble is, that if you have a way to check
for latency, try that as well.

John
> Hi Ad Franse,
>
> My responses embedded below:
>
>> pity that the value of getlasterror is not shown.
>
> Do you mean the integer value instead of the string returned by
> SysErrorMessage() ?
>
>>
>> questions :
>>
>> what compiler ?
>
> Delphi 7
>
>> unicode ?
>
> I'm using string not widestring. Hmm, could it be that the filename
> contains unicode characters and that by the time it reaches CopyFile it
> is nonsense...?
>
>> are the files copied or not ?
>
> Not.
>
>> can explorer.exe do it ?
>
> Will report back on that.
>>
>> the path is long (>=143 characters)
>> if \\ad11\fortress$ translates to a string of more than 117 characters
>> then the complete string is larger than _MAX_PATH (the solution is to
>> prefix with \\.\ in that case the complete path cannot exceed 32k - 1.
>
> Good point, I'm checking the full path of that share. Having said
> that, I have had issues in the path where users, frustrated by the path
> limitations, found a workaround by sharing a folder a good way down the
> path and then mapping a drive to it. This caused other code to fail
> where I was trying to copy *from* such a location have expanded to a
> full UNC path that was then > _MAX_PATH.
>
> I have also experimented with prefixes (\\?\ and \\UNC\) but my
> /recollection/ was that some functions (e.g. CopyFile) didn't like the
> prefixes.
>
>>
>> I found some reports for copyfile having trouble with readonly files
>> (your files are on CD)
>
> Indeed mine are on CD. In fact since my original post, I had the user
> copy the CD to a folder on the server and to run the import function
> from there and all worked fine which, as I write this sentence,
> suggests that the output path length is not the issue...
>
> Will report back more when available.
>
> Cheers
> Dave
>

John Turner wrote:

> Dave,
>
> FWIW,
>
> I've encountered the same problems with both Citrix sessions and
> Remote Desktop sessions,(MS forced Citrix to create this feature and
> build it into the MS Server OS's starting in 1997).
>
> I've also encountered similar problems recently when implementing
> code that uses the clipboard.
>
> File and clipboard operations sometimes become victims of the least
> bit of latency on thin client sessions. The differences can be very
> subtle as I have found that a file copy operation will work properly
> one time and not a second time from a wireless laptop running a
> remote desktop...then I'll disconnect the session, reconnect to the
> same session from a wired desktop and have it run fine...Then go back
> to the original laptop, connect it via cable and voila it works also.
>
> So, I guess the point of my dribble is, that if you have a way to
> check for latency, try that as well.
>
> John
> > Hi Ad Franse,
> >
> > My responses embedded below:
> >
> > > pity that the value of getlasterror is not shown.
> >
> > Do you mean the integer value instead of the string returned by
> > SysErrorMessage() ?
> >
> > >
> > > questions :
> > >
> > > what compiler ?
> >
> > Delphi 7
> >
> > > unicode ?
> >
> > I'm using string not widestring. Hmm, could it be that the filename
> > contains unicode characters and that by the time it reaches
> > CopyFile it is nonsense...?
> >
> > > are the files copied or not ?
> >
> > Not.
> >
> > > can explorer.exe do it ?
> >
> > Will report back on that.
> > >
> > > the path is long (>=143 characters)
> > > if \\ad11\fortress$ translates to a string of more than 117
> > > characters then the complete string is larger than _MAX_PATH (the
> > > solution is to prefix with \\.\ in that case the complete path
> > > cannot exceed 32k - 1.
> >
> > Good point, I'm checking the full path of that share. Having said
> > that, I have had issues in the path where users, frustrated by the
> > path limitations, found a workaround by sharing a folder a good way
> > down the path and then mapping a drive to it. This caused other
> > code to fail where I was trying to copy from such a location have
> > expanded to a
> >full UNC path that was then > _MAX_PATH.
> >
> > I have also experimented with prefixes (\\?\ and \\UNC\) but my
> > /recollection/ was that some functions (e.g. CopyFile) didn't like
> > the prefixes.
> >
> > >
> > > I found some reports for copyfile having trouble with readonly
> > > files (your files are on CD)
> >
> > Indeed mine are on CD. In fact since my original post, I had the
> > user copy the CD to a folder on the server and to run the import
> > function from there and all worked fine which, as I write this
> > sentence, suggests that the output path length is not the issue...
> >
> > Will report back more when available.
> >
> > Cheers
> > Dave
> >

Hi John

This is still on-going. I followed Michaël's suggestion and changed
the code to use SHFileOperation() to copy the files.

This didn't cure the problem but it did lead to a more meaningful (?)
error message i.e. "Error 0x800700F0: The session was canceled"

I've been working on the assumption that it is the citrix session
timing out (this process can run for several hours) and I've put code
in to simulate both mouse and keyboard activity every ~30mins to make
citrix think the user is still around. Sadly, this code doesn't seem
to 'fire' properly when running under citrix - it updates the form's
caption too so I know whether/when it last fired and it's not updating.

Citrix (or as I call it, Shitrix) is a real PITA...

Dave