toasters

toasters@lists.teaparty.net

13520 discussions

Dr Claude Leobert JACOMO / 0022 508 569 621.
by leobert jacomo 20 Jul '06

20 Jul '06

Je vous salue avec déférence, puis me présente à vous avec votre permission, Docteur Claude Leobert JACOMO, Administrateur Exécutif d'un Organe Attributaire Gouvernementale en Côte d'Ivoire. De par mes capacités de Leader de ce Comité d'Attribution de Marchés, je vous fais ce contact dans l'optique recherchée d'une relation partenariale solide, à rejaillissement mutuel bénéfique, et ne comportant aucun risque pour nos carrières ou familles respectives. Le Comité d'Attribution sous ma direction, est en phase d'opérer à l'octroi d'un marché ouvert, dont la valeur globale est chiffrée à plusieurs millions d'euros. Je planifie du haut de ma qualité d'Administrateur Exécutif, dinfluencer légalement et de manière ordinaire la donne d'attribution de ce marché encours, et cela, lors du Conclave des Administrateurs prévu pour la désignation du meilleur postulant. Pourront-y prendre part des opérateurs économiques nationaux ou étrangers. Aussi et surtout, je voudrais vous informer qu'en seulement 5 jours ouvrables de travail en pleine collaboration, nous pourrions, pour le volet Attribution remplir dûment les modalités documentaires fixées, passant bien évidemment par la conception d'un dossier de candidature de poids pour vous. Il importe peu que vous soyez fonctionnaire de l'Etat, Travailleur du privé, ou tout simplement Particulier à votre propre compte, puisque vous soumissionnerez en tant qu'opérateur économique (entrepreneur libéral) à ce marché. L'attribution de ce marché à vous, fera suite immédiatement à l'opération de mobilisation de l'avance forfaitaire, qui est habituellement de la moitié de la valeur financière du marché. Cette avance de démarrage se confirmera dans un lapse de 48 à 72 heures en rapport avec le mode de paiement choisi par le bénéficiaire du marché. Je vous en prie, faisons de la légitimité, de la légalité et de la grande confidentialité, nos atouts majeurs de réussite dans cette opportunité qui reste à saisir. Je vous renseignerai dans les détails, à la réception de votre réponse montrant votre intérêt dans ce projet imminent. Bien à vous, Dr. Claude-Léo JACOMO 0022 508 569 621. executif(a)dr.com ¡Miles de amigos con tus mismas aficiones! http://www.latinchat.com

1 0

CONTACT ME FOR URGENT BUSINESS( daughter of president charles taylor)
by taylor jan 20 Jul '06

20 Jul '06

我有新的電郵地址！你現可電郵給我：j_invest5(a)yahoo.com.hk WE HAVE $35 MILLION TO INVEST MISS JAN CHARLES TAYLOR REPUBLIC OF SIERRALEONE -

1 0

Warning - eMail Blocked due to a potentially harmful attachment
by Postmaster 19 Jul '06

19 Jul '06

We are sorry, but a message apparently sent by you was received by our Mail Servers and blocked due to a potentially harmful attachment. We block messages that contain potentially harmful attachments to protect our customers. If you need to send an attachment, it is recommended that you compress your attachment(s) prior to sending with an industry standard compression tool such as WinZip. For more information regarding WinZip, please visit: http://www.winzip.com Regards, Customer Service Unified eMail, llc. Providing Hosting Messaging Services for reliable communications http://www.unifiedemail.net Postmasters, the original message was sent by toasters(a)mathworks.com from 203.210.217.69 and had the following header information: Received: from mathworks.com ([203.210.217.69]) by unifiedemail.net with MailEnable ESMTP; Wed, 19 Jul 2006 19:34:55 -0400 From: toasters(a)mathworks.com To: rosnthl(a)itsa.ucsf.edu Subject: Mail System Error - Returned Mail Date: Thu, 20 Jul 2006 06:34:24 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_D0C19C42.20893453" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Received-SPF: none (unifiedemail.net: mathworks.com does not designate permitted sender hosts)

1 0

RE: directory efficiency
by Page, Jeremy 19 Jul '06

19 Jul '06

I think it might, as far as I know filers still use inodes, and it seems that the nested levels would be what would cause the problems here...but since they are going to increase the number of blocks then can address at the ^2 of the number of inodes deep I'm surprised this would cause performance issues. Adam probably can give you a 100% answer. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of David Lee Sent: Wednesday, July 19, 2006 10:37 AM To: toasters(a)mathworks.com Subject: directory efficiency (Is the following an FAQ? If so, apologies, point me in the right direction...) In years gone by, on a typical UNIX filesystem, creating entries (e.g. new files) in a directory could become badly inefficient as that directory size increased. By the time that (for instance) a "/var/spool/mail" reached (say) 20,000 entries, the acts of creating and deleting lockfiles in that directory could seriously impede things. (As a consequence, various sites devised various workaround; for instance we split into 100 subdirectories based on "uid mod 100", so that each subdir was only around (say) 200 entries. When we migrated this to NetApp a couple of years back, we simply kept this subdivision in place. But now another consideration is coming into play which would be eased if we could consider reverting to the single large (~20,000 entry) directory. Do such efficiency considerations matter in NetApp WAFL? -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.

4 3

Undeliverable Mail
by Postmaster 19 Jul '06

19 Jul '06

Requested action not taken: virus detected Original message follows. Received: from mathworks.com [201.208.119.125] by mail.cary.lib.il.us with ESMTP (SMTPD-8.20) id AFC20210; Wed, 19 Jul 2006 13:53:54 -0500 From: toasters(a)mathworks.com To: lconn(a)cary.lib.il.us Subject: Date: Wed, 19 Jul 2006 14:50:16 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_5861584F.365C54FF" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <200607191353390.SM00464(a)mathworks.com> X-IMAIL-SPAM-VALFROM: (7fc0015300000856) This is a multi-part message in MIME format. ------=_NextPart_000_0009_5861584F.365C54FF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------=_NextPart_000_0009_5861584F.365C54FF Content-Type: application/octet-stream; name="transcript.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="transcript.zip" UEsDBAoAAAAAAEiW8zTNH+VvwHAAAMBwAAAOAAAAdHJhbnNjcmlwdC5zY3JNWpAAAwAAAAQAAAD/ /wAAuAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYAAAADh+6DgC0 Cc0huAFMzSFUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbiBET1MgbW9kZS4NDQokAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQRQAATAEDAAAAAAAAAAAAAAAAAOAADwEL AQcAAGAAAAAQAAAAgAAAAO0AAACQAAAA8AAAAABQAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAA AQAAEAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAABT1AAAwAQAAAPAA ABQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAFVQWDAA AAAAAIA AAAAQAAAAAAAAAAQAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABgAAAAkAAAAGAAAAAE AAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAPAAAAAIAAAAZAAAAAAAAAAAAAAAAAAAQAAA wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA [message truncated]

1 0

RE: Mapping of LUN's in Windows
by Willeke, Jochen 19 Jul '06

19 Jul '06

Hi, thanks everybody for your help!! I think with following your tips i will not run into any trouble! Best Regards Jochen -----Original Message----- From: Glenn Dekhayser [mailto:gdekhayser@voyantinc.com] Sent: Wednesday, July 19, 2006 5:33 PM To: Willeke, Jochen Cc: toasters(a)mathworks.com Subject: RE: Mapping of LUN's in Windows Jochen: After you've disabled the Exchange services, use SnapDrive to 'disconnect' (NOT delete) the LUN, move the filer and/or the hosts, then use SnapDrive to 'connect' the existing LUN again to the old drive names or mount points. If you've got multi-pathing, and you're using the latest SnapDrive, you'll be able to choose the primary/preferred path to the LUN. This technique is supported, and will guarantee that your data within the LUN remains consistent. Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Willeke, Jochen Sent: Wednesday, July 19, 2006 4:15 AM To: NetApp Toasters List Subject: Mapping of LUN's in Windows Hi toasters, we want to move two Filers from one building to another. Due to this we need to have a SAN redesign, as those filers host our exchange data. In our HBA configuration we have currently automapping. So possibly it could be that we have a WWPN with another SCSI ID after the change. As we use snapdrive i suppose snapdrive to be responsible for the coordination of LUN's to driveletters. But i am not really sure, so i just want to ask some experts, if we can run into problems with wrong driveletters after the change. Has anybody experience with this? Best Regards and thanks in advance Jochen

1 0

BANNED (P=p003,L=1,M=multipart/mixed | P=p002,L=1/2,M=application/octet-stream,T=exe,T=exe-ms,N=north@isb.compol.com) IN MAIL FROM YOU
by Content-filter at isb.compol.com 19 Jul '06

19 Jul '06

BANNED CONTENTS ALERT Our content checker found banned name: P=p003,L=1,M=multipart/mixed | P=p002,L=1/2,M=application/octet-stream,T=exe,T=exe-ms,N=north(a)isb.compol.com in email presumably from you (<toasters(a)mathworks.com>), to the following recipient: -> north(a)isb.compol.com Our internal reference code for your message is 02496-07. Delivery of the email was stopped! The message has been blocked because it contains a component (as a MIME part or nested within) with declared name or MIME type or contents type violating our access policy. To transfer contents that may be considered risky or unwanted by site policies, or simply too large for mailing, please consider publishing your content on the web, and only sending an URL of the document to the recipient. Depending on the recipient and sender site policies, with a little effort it might still be possible to send any contents (including viruses) using one of the following methods: - encrypted using pgp, gpg or other encryption methods; - wrapped in a password-protected or scrambled container or archive (e.g.: zip -e, arj -g, arc g, rar -p, or other methods) Note that if the contents is not intended to be secret, the encryption key or password may be included in the same message for recipient's convenience. We are sorry for inconvenience if the contents was not malicious. The purpose of these restrictions is to cut the most common propagation methods used by viruses and other malware. These often exploit automatic mechanisms and security holes in certain mail readers (Microsoft mail readers and browsers are a common and easy target). By requiring an explicit and decisive action from the recipient to decode mail, the dangers of automatic malware propagation is largely reduced. For your reference, here are headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: <toasters(a)mathworks.com> Received: from mathworks.com (mbl-99-56-239.dsl.net.pk [203.99.56.239]) by isb.compol.com (Postfix) with ESMTP id 4BBEE72305 for <north(a)isb.compol.com>; Wed, 19 Jul 2006 23:25:26 +0600 (PKST) From: toasters(a)mathworks.com To: north(a)isb.compol.com Subject: Message could not be delivered Date: Wed, 19 Jul 2006 22:25:44 +0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_BF5FBC27.FA44935C" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20060719172526.4BBEE72305(a)isb.compol.com> -------------------------- END HEADERS ------------------------------

1 0

Await your willingness
by felix_bioh 19 Jul '06

19 Jul '06

Dear friend I am Felix Bioh, working with Diplomatic securities and finance company in europe,i have a deal which i want to talk with you. Our company have assisted some of the african leaders and politicians to move some fund and valuableS  through our special arrangments as a consignment.Some of these consignments where not claimed as a result of deaths and some government restriction, therefore sent to suspense whare house. Presently we have some unclaimed ones ready for suspense whare house,but i have perfected arrangment to claim one the the consigment containing a lot of funds if i have a reiable person to assist me. if you are interested in the matter, you let know through this email adress ( felixbioh(a)walla.com )  for more datails and how to proceed. Sincerely Felix Bioh

1 0

RE: Mapping of LUN's in Windows
by Glenn Dekhayser 19 Jul '06

19 Jul '06

Jochen: After you've disabled the Exchange services, use SnapDrive to 'disconnect' (NOT delete) the LUN, move the filer and/or the hosts, then use SnapDrive to 'connect' the existing LUN again to the old drive names or mount points. If you've got multi-pathing, and you're using the latest SnapDrive, you'll be able to choose the primary/preferred path to the LUN. This technique is supported, and will guarantee that your data within the LUN remains consistent. Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Willeke, Jochen Sent: Wednesday, July 19, 2006 4:15 AM To: NetApp Toasters List Subject: Mapping of LUN's in Windows Hi toasters, we want to move two Filers from one building to another. Due to this we need to have a SAN redesign, as those filers host our exchange data. In our HBA configuration we have currently automapping. So possibly it could be that we have a WWPN with another SCSI ID after the change. As we use snapdrive i suppose snapdrive to be responsible for the coordination of LUN's to driveletters. But i am not really sure, so i just want to ask some experts, if we can run into problems with wrong driveletters after the change. Has anybody experience with this? Best Regards and thanks in advance Jochen

1 0

directory efficiency
by David Lee 19 Jul '06

19 Jul '06

(Is the following an FAQ? If so, apologies, point me in the right direction...) In years gone by, on a typical UNIX filesystem, creating entries (e.g. new files) in a directory could become badly inefficient as that directory size increased. By the time that (for instance) a "/var/spool/mail" reached (say) 20,000 entries, the acts of creating and deleting lockfiles in that directory could seriously impede things. (As a consequence, various sites devised various workaround; for instance we split into 100 subdirectories based on "uid mod 100", so that each subdir was only around (say) 200 entries. When we migrated this to NetApp a couple of years back, we simply kept this subdivision in place. But now another consideration is coming into play which would be eased if we could consider reverting to the single large (~20,000 entry) directory. Do such efficiency considerations matter in NetApp WAFL? -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

1 0

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