Just a shot in the dark, but … Since you said it was file format/extension dependent I’d check the file associations for .rpt files and see what program is set to deal with them. I’m guessing that may be different between the working XP clients and the failing Win7 clients.
--
There are 10 kinds of people in the world...
those who understand binary and those who don't.
From: [email protected] [mailto:[email protected]] On
Behalf Of David Lum
Sent: Thursday, March 20, 2014 12:30 PM
To: [email protected]
Subject: RE: [NTSysADM] 64-bit GUI file copy puzzler
No special shell extensions. I did find out the 32-bit systems that they said
it did work on was an XP machine, so this morning I tested on a 32-bit Windows
7 VM and it also failed. We use Microsoft Antimalware here and turning it off
has no effect.
-Dave Lum
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Ken Schaefer
Sent: Wednesday, March 19, 2014 3:30 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] 64-bit GUI file copy puzzler
What Explorer shell extensions do you have loaded?
Any data-loss-prevention/AV type products involved?
Cheers
Ken
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of David Lum
Sent: Thursday, 20 March 2014 3:01 AM
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] 64-bit GUI file copy puzzler
Yes the SAN is providing CIFS.
It seems very specific to the contents of the file. I can copy
THISFILENAME.XLSX to the SAN location
(\\SANVOLUME\SHARE1<file:///\\SANVOLUME\SHARE1>, for example) just fine, but
REPORT.RPT fails to the same location. However, if I edit REPORT.RPT in Notepad
by one byte then save to my 64-bit PC THEN copy it, it works. Also, the
unmodified file works if I use XCOPY at the command prompt on the 64-bit
machine.
It’s something in the contents of the file, or some attribute the 64-bit GUI
gives it, or a combination.
-Dave Lum
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Kurt Buff
Sent: Tuesday, March 18, 2014 1:53 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [NTSysADM] 64-bit GUI file copy puzzler
Hrrmmmm...
I take it the SAN is actually providing CIFS storage?
How long are the file/directory path specifications for the files being copied?
If they're greater than approximately 250 characters
(x:\reall\long\directory\andfilename.rpt), the Windows file system doesn't like
it (the Win32 API governs this, and character encoding, etc., play some role in
exactly how many characters you can get away with). Robocopy used the Windows
Native API, which allows for ridiculously long path names - something like 32k
See, for instance, this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
Is it perhaps a limitation similar to that?
Kurt
On Tue, Mar 18, 2014 at 7:35 AM, David Lum
<[email protected]<mailto:[email protected]>> wrote:
Over the weekend there was an upgrade to our SAN systems. We now have this
bizarre issue where Crystal Reports .RPT files are unable to be copied from a
PC to the SAN shares via Windows 64-bit GUI.
Renaming an Excel file to .RPT: works
Use a 32-bit system to copy the file: works
Any other file (PDF, XLS, etc.): works
Using XCOPY on a 64-bit machine: works
It only fails when using the GUI on a 64-bit system, and it’s only on these
Crystal Reports .RPT files. If I open one of these RPT files on a 64-bit
machine with Notepad, change one byte, save it to the PC I can then copy it
over.
Ideas?
[cid:[email protected]]
David Lum
Network System Admin, Information Services
office 503-265-4728<tel:503-265-4728> |
modahealth.com<http://www.modahealth.com/>
I’m excited to announce that ODS Health is now Moda Health. Please make a note
of my new email address,
[email protected]<mailto:[email protected]>, so we can stay
connected.
This message is intended for the sole use of the individual and entity to whom
it is addressed, and may contain information that is privileged, confidential
and exempt from disclosure under applicable law. If you are not the intended
addressee, nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone the
message or any information contained in the message. If you have received this
message in error, please immediately advise the sender by reply email and
delete the message.
<<inline: image001.jpg>>
