It’s not extension dependent, I can rename an Excel file to excelfile.rpt and the file copies fine.
-Dave Lum From: [email protected] [mailto:[email protected]] On Behalf Of Melvin Backus Sent: Thursday, March 20, 2014 9:37 AM To: [email protected] Subject: RE: [NTSysADM] 64-bit GUI file copy puzzler 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]> [mailto:[email protected]] On Behalf Of David Lum Sent: Thursday, March 20, 2014 12:30 PM To: [email protected]<mailto:[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>>
