toasters

toasters@lists.teaparty.net

13515 discussions

RE: Possible CIFS bug?
by Hawley, Rob 19 Apr '00

19 Apr '00

We store the time as GMT in UNIX format, but we have to report it in NT, or DOS format. The NT article you cited is not complete. The time is reported in time zone corrected GMT or as local wall clock time depending on the type of request. Both require the client and server agree on the time zone configuration. Here is a quote on File Times from MSDN If the original date and time of day are specified in the local time for your time zone, you can convert the resulting file time to UTC by using the LocalFileTimeToFileTime function. Always make sure the file times you set using SetFileTime are valid UTC-based times. The FileTimeToLocalFileTime and LocalFileTimeToFileTime functions use the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, these functions will take daylight saving time into account, even if the time you are converting is in standard time. You should also consult Q158588 Please verify that both the client and server are set to the correct time zone. If this does not solve the problem then please contact NetApp customer support so we can get to the bottom of what you are seeing. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mailto: hawleyr(a)netapp.com US Mail: Network Appliance Inc. Phone: 408-822-6661 495 East Java Drive FAX: 408-822-4521 Sunnyvale, CA 94089 -----Original Message----- From: Marc A Levy [mailto:malevy@dnrc.bell-labs.com] Sent: Wednesday, April 19, 2000 5:55 AM To: toasters Subject: Possible CIFS bug? After the daylight savings time change a few weeks back I noticed something odd on the drives I have mapped to a NetApp. On a weekly basis (or so) I like to synchronize my home directory on the NetApp with a copy I keep on my home computer. I have been using a shareware program called "FileSync" which compares two directory trees based on file name, size, and date. There is also a option to do a binary compare (takes much longer, obviously). So, on to the problem: After the time change from EST to EDT, all of the files on the NetApp are exactly one hour older than on my home computer. Based on a little experimentation I did on the PC, I found that when the option to adjust for daylight savings time is disable on the Windows NT machine, all time appearances on the files (including the ones on filer) change by 1 hour. A article on the MSKB states that NT stores all file times in GMT, and converts the display based on the time zone setting on the PC. I am told that the NetApp stores this information in a UNIX format where it is a 32-bit integer which is "the number of seconds since Jan 1, 1970" I would suspect that CIFS converts this to GMT for compliance with Windows based on the time zone setting. It would seem there is a error in this conversion where the GMT on the file changes with the Time Zone setting (EST vs EDT). The calculation for GMT should be such that no matter what your time zone setting (even if you move your filer from EST to PST) the stamp on the file should remain constant. So, is this a bug? or some specific problem I am having? Thanks, Marc

1 0

Reading OnTap dump format on non NetApp systems
by Garrett Burke 19 Apr '00

19 Apr '00

Hi All, I understand that Solaris ufsdump can read (but drops ACL information) Netapp dump format tapes. Does anyone know if either FreeBSD or Red Hat Linux can do the same (don't have a drive on these systems at present so can't test it) or if there's any utility that enables them (or WinNT) to do so. We are primarily a WinNT house and what I'm trying to do is to ensure that in the face of a disaster, that I'm able to restore files as quickly as possible, even in the face of not having a filer (Even restoring a sub set of the files would get us back up & running) I'm not too worried about loosing the ACL information using this scenario. I'm currently looking at backup SW to replace our current system (ARCServe IT), but discovered that if we use NDMP (with QuickRestore) to backup the filer then the tapes will have Filer dump format information on them. Thanks, GB. ******************************************************************* This email and any files transmitted with it are confidential and are solely for the use of the individual or organisation to whom they are addressed. If you have received this mail in error please notify the system administrator at +353 1 6399700 or by email to hostmaster(a)msc.ie This email message has been swept for computer viruses. Managed Solutions Corporation, Enterprise Customer Relationship Management, Workflow and Contract Administration. Tel: 353 1 639 9700 Fax: 353 1 639 9701 Don't forget to visit our website at http://www.managed-solutions.com ********************************************************************

2 1

Re: Problems with MS Excel and Oplocks?
by Patrick Day 19 Apr '00

19 Apr '00

we had a similar problem, when we upgraded to 5.3.4R3P2 we no longer had any issues. you might want to upgrade to the latest version if you haven't already. --Patrick Day "DDA.RFC-822=demarest(a)arraycomm.com/P=Internet/A= /C=us"@X400@mathworks.com on 04/18/2000 05:53:34 PM Please respond to "DDA.RFC-822=demarest(a)arraycomm.com/P=Internet/A= /C=us"@X400 Sent by: owner-toasters(a)mathworks.com To: "DDA.RFC-822=toasters(a)mathworks.com/P=Internet/A= /C=us"@X400 cc: Subject: Problems with MS Excel and Oplocks? I've seen a strange problem over the past few days. We have MS Windows 9x/NT users running Excel 97 and Excel 2000. Dozens of minutes, or even hours, after a person stops editing the file (Save & Quit), you can't access the file via NFS or CIFS. CIFS apps complain the file is in use. NFS clients complain with "permission denied". Doing a truss of a chmod or rm on the file shows ERR#13 - EACCES. The only way to "unlock" the file is t have the CIFS user logoff of the client, or to terminate the CIFS session of the Filer. The user clearly does not have any apps open on the CIFS client. This sounds suspiciously like Windows 9x/NT and Excel is doing something weird to keep the lock open. Has anyone seen this with Excel, and how did they resolve it? Tim -- Timothy Demarest ArrayComm, Inc. demarest(a)arraycomm.com 2480 North 1st Street, Suite 200 http://www.arraycomm.com San Jose, CA 95131

1 0

Possible CIFS bug?
by Marc A Levy 19 Apr '00

19 Apr '00

After the daylight savings time change a few weeks back I noticed something odd on the drives I have mapped to a NetApp. On a weekly basis (or so) I like to synchronize my home directory on the NetApp with a copy I keep on my home computer. I have been using a shareware program called "FileSync" which compares two directory trees based on file name, size, and date. There is also a option to do a binary compare (takes much longer, obviously). So, on to the problem: After the time change from EST to EDT, all of the files on the NetApp are exactly one hour older than on my home computer. Based on a little experimentation I did on the PC, I found that when the option to adjust for daylight savings time is disable on the Windows NT machine, all time appearances on the files (including the ones on filer) change by 1 hour. A article on the MSKB states that NT stores all file times in GMT, and converts the display based on the time zone setting on the PC. I am told that the NetApp stores this information in a UNIX format where it is a 32-bit integer which is "the number of seconds since Jan 1, 1970" I would suspect that CIFS converts this to GMT for compliance with Windows based on the time zone setting. It would seem there is a error in this conversion where the GMT on the file changes with the Time Zone setting (EST vs EDT). The calculation for GMT should be such that no matter what your time zone setting (even if you move your filer from EST to PST) the stamp on the file should remain constant. So, is this a bug? or some specific problem I am having? Thanks, Marc

1 0

RE:
by Bond, Andrew 19 Apr '00

19 Apr '00

You should talk to NetApp support if you are having a problem with this. However, there is nothing to do on the filer. If the autoloader is correctly configured, then using the urst0a device name will cause autoloading to occur. See the manpage for na_tape.4 for more detail. Regards, Andrew > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of > bhaskar.g(a)philips.com > Sent: 19 April 2000 05:31 > To: toasters(a)mathworks.com > Subject: > > > Hi All, > > We have a Filer 720 with two shelves. We are having a DLT > 7000 Autoloader ( Dell Powervault 120T ) for the > backup of the filer. Please let me know how to enable the > autoloading option 'ON' on the filer. > > regards > Bhaskar G > Systems Engineer, > Philips Semiconductors, > #3, Sterling Square,Madras Bank Road, > Off St Mark's Road,BANGALORE-560 001. > Voice : +91 80 222 9200 Ext 1478 > Fax: +91 80 2229700 > >

1 0

None
by bhaskar.g＠philips.com 19 Apr '00

19 Apr '00

Hi All, We have a Filer 720 with two shelves. We are having a DLT 7000 Autoloader ( Dell Powervault 120T ) for the backup of the filer. Please let me know how to enable the autoloading option 'ON' on the filer. regards Bhaskar G Systems Engineer, Philips Semiconductors, #3, Sterling Square,Madras Bank Road, Off St Mark's Road,BANGALORE-560 001. Voice : +91 80 222 9200 Ext 1478 Fax: +91 80 2229700

1 0

RE: Problems with MS Excel and Oplocks?
by Day, Matt 18 Apr '00

18 Apr '00

> I've seen a strange problem over the past few days. We have MS Windows > 9x/NT users running Excel 97 and Excel 2000. Dozens of minutes, or even > hours, after a person stops editing the file (Save & Quit), you can't > access the file via NFS or CIFS. CIFS apps complain the file is in use. > NFS clients complain with "permission denied". Doing a truss of a chmod > or rm on the file shows ERR#13 - EACCES. The only way to "unlock" the > file is to have the CIFS user logoff of the client, or to terminate the > CIFS session of the Filer. The user clearly does not have any apps open > on the CIFS client. > > This sounds suspiciously like Windows 9x/NT and Excel is doing > something weird to keep the lock open. Has anyone seen this with Excel, > and how did they resolve it? That does sound like an oplock problem. What version of Data ONTAP are you running? Can you run "cifs stat" on your filer and send me the output? I'm interested in knowing what your OpLkBkNoBreakAck statistic is. You may be suffering from non-responsive oplock breaks. If you disable oplocks (set the cifs.oplocks.enable option off) and the problem goes away, then that's almost certainly the problem. I suspect a newer version of Data ONTAP will help a lot. In more recent versions there is a knob for working around the non-responsive oplock break problem (a very irritating bug in the Microsoft client). Matt

1 0

Problems with MS Excel and Oplocks?
by Timothy Demarest 18 Apr '00

18 Apr '00

I've seen a strange problem over the past few days. We have MS Windows 9x/NT users running Excel 97 and Excel 2000. Dozens of minutes, or even hours, after a person stops editing the file (Save & Quit), you can't access the file via NFS or CIFS. CIFS apps complain the file is in use. NFS clients complain with "permission denied". Doing a truss of a chmod or rm on the file shows ERR#13 - EACCES. The only way to "unlock" the file is to have the CIFS user logoff of the client, or to terminate the CIFS session of the Filer. The user clearly does not have any apps open on the CIFS client. This sounds suspiciously like Windows 9x/NT and Excel is doing something weird to keep the lock open. Has anyone seen this with Excel, and how did they resolve it? Tim -- Timothy Demarest ArrayComm, Inc. demarest(a)arraycomm.com 2480 North 1st Street, Suite 200 http://www.arraycomm.com San Jose, CA 95131

1 0

Large vs Small Backups
by Moshe Linzer 18 Apr '00

18 Apr '00

Hi, We are using Budtool 4.6.1a to backup an F760 and an F630 to a Breece Hill Q2.15 jukebox with 2 DLT7000 drives. We backup each qtree as a separate request in budtool. We started getting poor performance on the smaller qtrees, and started using the hidden ndmpd logical_find command described in Bug 12424. We recently upgraded to 5.3.5P2, and I found that this option is causing ndmp connection problems between Budtool and the filer. As a result, I have backed off to 5.3.5, where this option works without a problem. My question: How best to backup a 330GB volume with many small qtrees? Should we just backup the entire volume as one request, or continue to backup each qtree individually? Are there any problems with backing up the entire volume at once? This will allow me to dump (no pun intended) the problematic ndmpd logical_find option, as well improve general dump performance. Thanks, Moshe ----------------------------------------------------------------------------- Moshe Linzer | Mastery of Unix offers real freedom. Unix Systems Manager | The price of freedom is always dear, but National Semiconductor, Israel | I'd rather pay for my freedom than live in Phone: 972-9-970-2247 | a bitmapped, pop-up-happy dungeon like NT. Fax: 972-9-970-2001 | Email: moshel(a)nsc.com | - Thomas Scoville, Unix Review -----------------------------------------------------------------------------

2 1

nfs.v3.enable
by Todd C. Merrill 18 Apr '00

18 Apr '00

I currently have this "on." If I turn this off, what will happen to V3 clients that currently have mounts to the filer? Put another way, is this option immediate, or does it only take affect on new mounts or a reboot of the filer? Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters