[Mono-list] Possible bug in MimeKit [or weird behavior? or I am stupid, and don't get it?]
First of all, thx for a brilliant piece of work Jeffrey, MimeKit and MailKit simply rules!! :D Anyway, there are some weird behavior in WindowsSecureMimeContext.cs in MimeKit which either I am too stupid to understand, or seems to be a bug ...? Inside the GetCmsRecipientCertificate method, you check for the DataEncipherment bit, and if found, MimeKit doesn't allow usage of certificate and/or key. I have a certificate from Comodo, which apparently seem to have this bit set, which means MimeKit doesn't allow me to use this certificate/key to do its magic. I actually forked your WindowsSecureMimeContext class just to remove this check, which allowed me to use that certificate and key Could someone explain to me please why this check is there ...? ps, Comodo seems to be one of the biggest certificate issuers out there, and if they issue their default email certificates with the DataEncipherment bit set, I imagine a lot of certificates are lost this way ... Another thing on the sideline, it took me actually a whole day figuring out I could use the Windows Certificate/Key Storage instead of Sqlite. Maybe you should update your website at https://github.com/jstedfast/MimeKit to at the very least inform users of that there exists a Windows Certificate/Key database wrapper in MimeKit ... When I found it, I had spent literally a whole day trying to make my own ... :P Anyway, thanx again for a brilliant piece of work :D I've looked at all the smtp and s/mime libraries out there, and MimeKit simply rules ... :D pps, could anyone point me in the direction for the changelog for version 0.94 of both MimeKit and MailKit ...? ppps, if this is the wrong mailing list, I am sorry for being off topic, and I would appreciate someone pointing me in the right direction :) Have a nice day :) Thomas ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible bug in MimeKit [or weird behavior? or I am stupid, and don't get it?]
From: mono-list-boun...@lists.ximian.com [mailto:mono-list- boun...@lists.ximian.com] On Behalf Of Thomas Hansen First of all, thx for a brilliant piece of work Jeffrey, MimeKit and MailKit simply rules!! :D +1 I don't think Jeff is on this mailing list, so I added him to BCC, so he's both included in this message I'm sending, and I'm not giving away his email address (just in case he cares. Although I don't think he does.) Inside the GetCmsRecipientCertificate method, you check for the DataEncipherment bit, and if found, MimeKit doesn't allow usage of certificate and/or key. I have a certificate from Comodo, which apparently seem to have this bit set, which means MimeKit doesn't allow me to use this certificate/key to do its magic. I actually forked your WindowsSecureMimeContext class just to remove this check, which allowed me to use that certificate and key This question really has touched on several independent subjects. #1 When you get a cert, the cert issuer sets bits on the cert, indicating how it's intended to be used. They can issue signing-only certs, signing encrypting certs, etc. So what is the DataEncipherment bit? See http://tools.ietf.org/html/rfc5280#section-4.2.1.3 It's exactly what you think it is. If the bit is set, then the issuer intends this cert to be usable for encryption. #2 You said, if the bit is set, MimeKit disallows usage of the cert. You have a cert with that bit set, and it won't work. This seems to be reverse logic - seems to suggest a bug in MimeKit - but maybe it's in fact correct (I don't want to jump to conclusions.) To me it seems like the logic clause is probably accidentally negated. Sounds like a bug to me. #3 Suppose the logic is correct. Suppose the bit is *supposed* to prevent you from using this cert this way. Then is it ok to simply reverse the logic in the application and use it anyway? No, not really. It might work, and it might even be secure, but the purpose of setting those bits is to ensure proper usage, and anything used incorrectly in cryptography is prone to weakness. For example, what's the difference between an ECDSA key and an ECDH key? None. They're exactly the same. In fact, either EC key can work in either situation, but the best practices for key storage are different, and if the same key is used for both DSA and DH, the interactions of these two protocols have not been rigorously studied and vetted by the community, so there could possibly exist bad interactions that break security, if only somebody bothers to put in the effort and study it. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible bug checking existence of file or directory
On 11/05/2010 03:15 AM, Abe Gillespie wrote: If this is a bug I'll file it: Doing File.Exists() or Directory.Exists() on a file / dir that the running account doesn't have permission to causes this to return false. This is somewhat understandable (but is it correct?). However, doing a new FileSystemWatcher() on the same existing, but not accessible dir, throws a DirectoryNotFoundException(). This seems a little less understandable. But I'm not sure. You forgot to specify your expected results. If you ask me about the above examples, I would expect the actual results. -- Piotr Wysocki Mobile Systems Research Labs, Poznan University of Technology ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible bug checking existence of file or directory
Doing File.Exists() or Directory.Exists() on a file / dir that the running account doesn't have permission to causes this to return false. This is somewhat understandable (but is it correct?). This matches what MSDN says. Return Value true if the caller has the required permissions and path contains the name of an existing file; otherwise, false. http://msdn.microsoft.com/en-us/library/system.io.file.exists%28v=VS.80%29.aspx I'm not sure about FileSystemWatcher throwing DirectoryNotFoundException, though. MSDN doesn't mention it (if we're indeed talking about the FileSystemWatcher constructor): http://msdn.microsoft.com/en-us/library/b36854c3.aspx Abe Gillespie wrote: If this is a bug I'll file it: Doing File.Exists() or Directory.Exists() on a file / dir that the running account doesn't have permission to causes this to return false. This is somewhat understandable (but is it correct?). However, doing a new FileSystemWatcher() on the same existing, but not accessible dir, throws a DirectoryNotFoundException(). This seems a little less understandable. But I'm not sure. -Abe ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Possible-bug-checking-existence-of-file-or-directory-tp3028067p3028357.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible bug checking existence of file or directory
Sorry, expected results - I would have expected an access violation from the FileSystemWatcher. But since it's official for .Net to act like the path doesn't exist, then maybe the FileSystemWatcher is behaving correctly. Will all this said, there is one small bug with FileSystemWatcher. When it throws the message is Directory does not exists (notice the plurality). I'll file it today. -Abe On Fri, Nov 5, 2010 at 5:27 AM, Stifu st...@free.fr wrote: Doing File.Exists() or Directory.Exists() on a file / dir that the running account doesn't have permission to causes this to return false. This is somewhat understandable (but is it correct?). This matches what MSDN says. Return Value true if the caller has the required permissions and path contains the name of an existing file; otherwise, false. http://msdn.microsoft.com/en-us/library/system.io.file.exists%28v=VS.80%29.aspx I'm not sure about FileSystemWatcher throwing DirectoryNotFoundException, though. MSDN doesn't mention it (if we're indeed talking about the FileSystemWatcher constructor): http://msdn.microsoft.com/en-us/library/b36854c3.aspx Abe Gillespie wrote: If this is a bug I'll file it: Doing File.Exists() or Directory.Exists() on a file / dir that the running account doesn't have permission to causes this to return false. This is somewhat understandable (but is it correct?). However, doing a new FileSystemWatcher() on the same existing, but not accessible dir, throws a DirectoryNotFoundException(). This seems a little less understandable. But I'm not sure. -Abe ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Possible-bug-checking-existence-of-file-or-directory-tp3028067p3028357.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Possible bug checking existence of file or directory
If this is a bug I'll file it: Doing File.Exists() or Directory.Exists() on a file / dir that the running account doesn't have permission to causes this to return false. This is somewhat understandable (but is it correct?). However, doing a new FileSystemWatcher() on the same existing, but not accessible dir, throws a DirectoryNotFoundException(). This seems a little less understandable. But I'm not sure. -Abe ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible Bug
Thanks very much. I am building using mkbundle on Mac OS X 10.5.8 from the Terminal Window. I have compiled the product (C# 2.0) with Visual Studio 2005.NET on Vista Professional ( only way I have ever compiled ). I don’t know much about how csc.exe works behind Visual Studio. I have never used gmcs to compile on mono – should I ? Is that better? I’ve attached the Visual Studio project (extremely basic). All I have listed in the unit (ManUnit.cs) is: using System; using System.Text; using System.Windows.Forms; But I notice in the Solution Tree under References it has the following: I’ll try to remove some to see if that helps. System System.Data System.Deployment System.Drawing System.EnterpriseServices System.Web.Services System.Windows.Forms System.XML Original post: http://n2.nabble.com/mkbundle-on-Mac-OSX-10-5-working-unexpected-like-td4586618.html#a4586618 Thanks, Dan. From: Abe Gillespie [via Software] [mailto:ml-node+4586762-1225967...@n2.nabble.com] Sent: February-17-10 10:58 To: d_v Subject: Re: Possible Bug Bug #580564 On Tue, Feb 16, 2010 at 7:42 PM, Michael Hutchinson [hidden email] http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=4586762i=0 wrote: On Tue, Feb 16, 2010 at 10:27 AM, Abe Gillespie [hidden email] http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=4586762i=1 wrote: I'll be happy to file a bug ... I just need more info. In visual studio you do *not* need a reference to System.Core to compile OK. So does csc.exe handle this differently from gmcs.exe or does visual studio automatically add a System.Core reference on-the-fly when a compile is fired off? Essentially, what bug(s) / what product(s) should I file this against? That's sounds like it's a gmcs issue then, not MD. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-list maillist - [hidden email] http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=4586762i=2 http://lists.ximian.com/mailman/listinfo/mono-list _ View message @ http://n2.nabble.com/Possible-Bug-tp4566842p4586762.html To start a new topic under Mono - General, email ml-node+1723-232802...@n2.nabble.com To unsubscribe from Mono - General, click (link removed) here. -- View this message in context: http://n2.nabble.com/Possible-Bug-tp4566842p4587172.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible Bug
Bug #580564 On Tue, Feb 16, 2010 at 7:42 PM, Michael Hutchinson m.j.hutchin...@gmail.com wrote: On Tue, Feb 16, 2010 at 10:27 AM, Abe Gillespie abe.gilles...@gmail.com wrote: I'll be happy to file a bug ... I just need more info. In visual studio you do *not* need a reference to System.Core to compile OK. So does csc.exe handle this differently from gmcs.exe or does visual studio automatically add a System.Core reference on-the-fly when a compile is fired off? Essentially, what bug(s) / what product(s) should I file this against? That's sounds like it's a gmcs issue then, not MD. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible Bug
I'll be happy to file a bug ... I just need more info. In visual studio you do *not* need a reference to System.Core to compile OK. So does csc.exe handle this differently from gmcs.exe or does visual studio automatically add a System.Core reference on-the-fly when a compile is fired off? Essentially, what bug(s) / what product(s) should I file this against? Thanks. -Abe On Sat, Feb 13, 2010 at 8:06 PM, Dino Viehland di...@microsoft.com wrote: Rather than just looking for System.Core MonoDevelop should really look for the System.Runtime.CompilerServices.ExtensionAttribute in any of the referenced assemblies. You can define this type in your own assembly and not reference System.Core and still use extension methods. We do this in IronPython so we can run on .NET 2.0SP1 and above but compile w/ the 3.5 compiler. From: mono-list-boun...@lists.ximian.com [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Michael Hutchinson Sent: Saturday, February 13, 2010 3:36 PM To: Abe Gillespie Cc: mono-list Subject: Re: [Mono-list] Possible Bug I guess MonoDevelop should not provide completion for extension methods when System.Core is not referenced. MD should also reference System.Core by default in new 3.5+ projects. Please file bugs. Arguably gmcs should give a better error message too, so please file a separate bug against gmcs for that. On Feb 13, 2010 11:37 AM, Abe Gillespie abe.gilles...@gmail.com wrote: Not sure if this is a bug or just some sugar that VS.NET does. If you have extension methods in one assembly and then use those extension methods in another, if you do not reference System.Core then the compiler can't find those methods. I think the big problem is it's hard to diagnose. MonoDevelop will happily offer code-completion for those extension methods. However, when you compile, it fails. Unfortunately the error info doesn't give you any sort of clue that it's a missing System.Core reference and *NOT* a missing method. VS.NET will happily offer code-completion *and* compile. Example of an error message: Messenger.cs(34,34): Error CS1061: Type `Dimebrain.TweetSharp.Fluent.IFluentTwitter' does not contain a definition for `AuthenticateAs' and no extension method `AuthenticateAs' of type `Dimebrain.TweetSharp.Fluent.IFluentTwitter' could be found (are you missing a using directive or an assembly reference?) (CS1061) (Infrastructure) The last part - are you missing a using directive [...] - is misleading because that makes me think I need to add a reference to TweetSharp. But what it really needs is the System.Core reference. Hope that's useful. Thanks! -Abe ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible Bug
On Tue, Feb 16, 2010 at 10:27 AM, Abe Gillespie abe.gilles...@gmail.com wrote: I'll be happy to file a bug ... I just need more info. In visual studio you do *not* need a reference to System.Core to compile OK. So does csc.exe handle this differently from gmcs.exe or does visual studio automatically add a System.Core reference on-the-fly when a compile is fired off? Essentially, what bug(s) / what product(s) should I file this against? That's sounds like it's a gmcs issue then, not MD. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Possible Bug
Not sure if this is a bug or just some sugar that VS.NET does. If you have extension methods in one assembly and then use those extension methods in another, if you do not reference System.Core then the compiler can't find those methods. I think the big problem is it's hard to diagnose. MonoDevelop will happily offer code-completion for those extension methods. However, when you compile, it fails. Unfortunately the error info doesn't give you any sort of clue that it's a missing System.Core reference and *NOT* a missing method. VS.NET will happily offer code-completion *and* compile. Example of an error message: Messenger.cs(34,34): Error CS1061: Type `Dimebrain.TweetSharp.Fluent.IFluentTwitter' does not contain a definition for `AuthenticateAs' and no extension method `AuthenticateAs' of type `Dimebrain.TweetSharp.Fluent.IFluentTwitter' could be found (are you missing a using directive or an assembly reference?) (CS1061) (Infrastructure) The last part - are you missing a using directive [...] - is misleading because that makes me think I need to add a reference to TweetSharp. But what it really needs is the System.Core reference. Hope that's useful. Thanks! -Abe ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible Bug
I guess MonoDevelop should not provide completion for extension methods when System.Core is not referenced. MD should also reference System.Core by default in new 3.5+ projects. Please file bugs. Arguably gmcs should give a better error message too, so please file a separate bug against gmcs for that. On Feb 13, 2010 11:37 AM, Abe Gillespie abe.gilles...@gmail.com wrote: Not sure if this is a bug or just some sugar that VS.NET does. If you have extension methods in one assembly and then use those extension methods in another, if you do not reference System.Core then the compiler can't find those methods. I think the big problem is it's hard to diagnose. MonoDevelop will happily offer code-completion for those extension methods. However, when you compile, it fails. Unfortunately the error info doesn't give you any sort of clue that it's a missing System.Core reference and *NOT* a missing method. VS.NET will happily offer code-completion *and* compile. Example of an error message: Messenger.cs(34,34): Error CS1061: Type `Dimebrain.TweetSharp.Fluent.IFluentTwitter' does not contain a definition for `AuthenticateAs' and no extension method `AuthenticateAs' of type `Dimebrain.TweetSharp.Fluent.IFluentTwitter' could be found (are you missing a using directive or an assembly reference?) (CS1061) (Infrastructure) The last part - are you missing a using directive [...] - is misleading because that makes me think I need to add a reference to TweetSharp. But what it really needs is the System.Core reference. Hope that's useful. Thanks! -Abe ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible Bug
Rather than just looking for System.Core MonoDevelop should really look for the System.Runtime.CompilerServices.ExtensionAttribute in any of the referenced assemblies. You can define this type in your own assembly and not reference System.Core and still use extension methods. We do this in IronPython so we can run on .NET 2.0SP1 and above but compile w/ the 3.5 compiler. From: mono-list-boun...@lists.ximian.com [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Michael Hutchinson Sent: Saturday, February 13, 2010 3:36 PM To: Abe Gillespie Cc: mono-list Subject: Re: [Mono-list] Possible Bug I guess MonoDevelop should not provide completion for extension methods when System.Core is not referenced. MD should also reference System.Core by default in new 3.5+ projects. Please file bugs. Arguably gmcs should give a better error message too, so please file a separate bug against gmcs for that. On Feb 13, 2010 11:37 AM, Abe Gillespie abe.gilles...@gmail.commailto:abe.gilles...@gmail.com wrote: Not sure if this is a bug or just some sugar that VS.NEThttp://VS.NET does. If you have extension methods in one assembly and then use those extension methods in another, if you do not reference System.Core then the compiler can't find those methods. I think the big problem is it's hard to diagnose. MonoDevelop will happily offer code-completion for those extension methods. However, when you compile, it fails. Unfortunately the error info doesn't give you any sort of clue that it's a missing System.Core reference and *NOT* a missing method. VS.NEThttp://VS.NET will happily offer code-completion *and* compile. Example of an error message: Messenger.cs(34,34): Error CS1061: Type `Dimebrain.TweetSharp.Fluent.IFluentTwitter' does not contain a definition for `AuthenticateAs' and no extension method `AuthenticateAs' of type `Dimebrain.TweetSharp.Fluent.IFluentTwitter' could be found (are you missing a using directive or an assembly reference?) (CS1061) (Infrastructure) The last part - are you missing a using directive [...] - is misleading because that makes me think I need to add a reference to TweetSharp. But what it really needs is the System.Core reference. Hope that's useful. Thanks! -Abe ___ Mono-list maillist - Mono-list@lists.ximian.commailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible bug in ConvertTimeToUtc(DateTime, TimeZoneInfo)?
Hi, I'll throw together a NUnit test tomorrow. Also, I have a tweaked version of my original patch (a little cleaner, fixes some function flow that doesn't effect the final outcome) that I'll send as well. Thanks! Kevin Reay On Mon, Sep 8, 2008 at 11:08 PM, Atsushi Eno [EMAIL PROTECTED] wrote: Hi, (I was reviewing old emails and found it left as is.) Thanks for the patch. Can you please add a NUnit test case as well? Then I'll check in the patch. Atsushi Eno KevinReay wrote: Ok, I tested the proposed changes locally (with changes/corrections) and they seem to work, at least for me. I've attached a (unified) diff for the changes I made, if anyone is interested (also attached inline). Diff seems to solve problem described above, and includes minor spelling/grammar tweak. Thanks, Kevin --- TimeZoneInfo.cs.old 2008-07-25 10:48:16.0 -0500 +++ TimeZoneInfo.cs 2008-07-25 10:53:07.0 -0500 @@ -222,10 +222,7 @@ throw new ArgumentNullException (sourceTimeZone); if (dateTime.Kind == DateTimeKind.Utc sourceTimeZone != TimeZoneInfo.Utc) - throw new ArgumentException (Kind propery of dateTime is Utc but the sourceTimeZone does not equal TimeZoneInfo.Utc); - - if (dateTime.Kind == DateTimeKind.Local sourceTimeZone != TimeZoneInfo.Local) - throw new ArgumentException (Kind propery of dateTime is Local but the sourceTimeZone does not equal TimeZoneInfo.Local); + throw new ArgumentException (dateTime Kind value is Utc but sourceTimeZone is not Utc); if (sourceTimeZone.IsInvalidTime (dateTime)) throw new ArgumentException (dateTime parameter is an invalid time); @@ -236,7 +233,7 @@ if (dateTime.Kind == DateTimeKind.Utc) return dateTime; - if (dateTime.Kind == DateTimeKind.Local) + if (dateTime.Kind == DateTimeKind.Local sourceTimeZone == TimeZoneInfo.Utc) return ConvertTimeToUtc (dateTime); if (sourceTimeZone.IsAmbiguousTime (dateTime) || !sourceTimeZone.IsDaylightSavingTime (dateTime)) http://www.nabble.com/file/p18658416/TimeZoneInfo.cs.diff TimeZoneInfo.cs.diff KevinReay wrote: Hi everyone, I think I may have spotted a bug in the System.TimeZoneInfo.ConvertTimeToUtc(DateTime, TimeZoneInfo) method. I could, of course, be wrong (clue-stick appreciated!). The following check appears to be wrong: if (dateTime.Kind == DateTimeKind.Local sourceTimeZone != TimeZoneInfo.Local) throw new ArgumentException (Kind propery of dateTime is Local but the sourceTimeZone does not equal TimeZoneInfo.Local); Shouldn't this code only check that if sourceTimeZone == TimeZoneInfo.Utc, as the sourceTimeZone could be represent a local timezone while still not being equal to TimeZoneInfo.Local (The system's local timezone)? As an example, the following code runs as expected under .Net/Windows: TimeZoneInfo _SpecifiedTimezone = TimeZoneInfo.FindSystemTimeZoneById(SpecifiedTimeZone); _NewMeeting.DateBegin = TimeZoneInfo.ConvertTimeToUtc(DateTime.Parse(SpecifiedDate), _SpecifiedTimezone); But fails with the following exception when run under mono: Kind propery of dateTime is Local but the sourceTimeZone does not equal TimeZoneInfo.Local Thanks, Kevin ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible bug in ConvertTimeToUtc(DateTime, TimeZoneInfo)?
Here is a more complete potential fix (not tested!):
public static DateTime ConvertTimeToUtc (DateTime dateTime, TimeZoneInfo
sourceTimeZone)
{
if (sourceTimeZone == null)
throw new ArgumentNullException (sourceTimeZone);
if (dateTime.Kind == DateTimeKind.Utc sourceTimeZone !=
TimeZoneInfo.Utc)
throw new ArgumentException (Kind propery of dateTime is Utc
but the
sourceTimeZone does not equal TimeZoneInfo.Utc);
if (dateTime.Kind == DateTimeKind.Local sourceTimeZone ==
TimeZoneInfo.Utc)
throw new ArgumentException (Kind propery of dateTime is Local
but the
sourceTimeZone does not equal TimeZoneInfo.Local);
if (sourceTimeZone.IsInvalidTime (dateTime))
throw new ArgumentException (dateTime parameter is an invalid
time);
if (dateTime.Kind == DateTimeKind.Utc sourceTimeZone ==
TimeZoneInfo.Utc)
return dateTime;
if (dateTime.Kind == DateTimeKind.Utc)
return dateTime;
if (dateTime.Kind == DateTimeKind.Local sourceTimeZone ==
TimeZoneInfo.Local)
return ConvertTimeToUtc (dateTime);
if (sourceTimeZone.IsAmbiguousTime (dateTime) ||
!sourceTimeZone.IsDaylightSavingTime (dateTime))
return DateTime.SpecifyKind (dateTime -
sourceTimeZone.BaseUtcOffset,
DateTimeKind.Utc);
else {
AdjustmentRule rule = sourceTimeZone.GetApplicableRule
(dateTime);
return DateTime.SpecifyKind (dateTime -
sourceTimeZone.BaseUtcOffset -
rule.DaylightDelta, DateTimeKind.Utc);
}
}
Note the inclusion of the sourceTimeZone == TimeZoneInfo.Local test before
the return ConvertTimeToUtc (dateTime); call.
Thanks again,
Kevin
KevinReay wrote:
Hi everyone,
I think I may have spotted a bug in the
System.TimeZoneInfo.ConvertTimeToUtc(DateTime, TimeZoneInfo) method. I
could, of course, be wrong (clue-stick appreciated!).
The following check appears to be wrong:
if (dateTime.Kind == DateTimeKind.Local sourceTimeZone !=
TimeZoneInfo.Local)
throw new ArgumentException (Kind propery of dateTime is Local but the
sourceTimeZone does not equal TimeZoneInfo.Local);
Shouldn't this code only check that if sourceTimeZone == TimeZoneInfo.Utc,
as the sourceTimeZone could be represent a local timezone while still not
being equal to TimeZoneInfo.Local (The system's local timezone)?
As an example, the following code runs as expected under .Net/Windows:
TimeZoneInfo _SpecifiedTimezone =
TimeZoneInfo.FindSystemTimeZoneById(SpecifiedTimeZone);
_NewMeeting.DateBegin =
TimeZoneInfo.ConvertTimeToUtc(DateTime.Parse(SpecifiedDate),
_SpecifiedTimezone);
But fails with the following exception when run under mono:
Kind propery of dateTime is Local but the sourceTimeZone does not equal
TimeZoneInfo.Local
Thanks,
Kevin
--
View this message in context:
http://www.nabble.com/Possible-bug-in-ConvertTimeToUtc%28DateTime%2C-TimeZoneInfo%29--tp18648344p18648612.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible bug in ConvertTimeToUtc(DateTime, TimeZoneInfo)?
Ok, I tested the proposed changes locally (with changes/corrections) and they seem to work, at least for me. I've attached a (unified) diff for the changes I made, if anyone is interested (also attached inline). Diff seems to solve problem described above, and includes minor spelling/grammar tweak. Thanks, Kevin --- TimeZoneInfo.cs.old 2008-07-25 10:48:16.0 -0500 +++ TimeZoneInfo.cs 2008-07-25 10:53:07.0 -0500 @@ -222,10 +222,7 @@ throw new ArgumentNullException (sourceTimeZone); if (dateTime.Kind == DateTimeKind.Utc sourceTimeZone != TimeZoneInfo.Utc) - throw new ArgumentException (Kind propery of dateTime is Utc but the sourceTimeZone does not equal TimeZoneInfo.Utc); - - if (dateTime.Kind == DateTimeKind.Local sourceTimeZone != TimeZoneInfo.Local) - throw new ArgumentException (Kind propery of dateTime is Local but the sourceTimeZone does not equal TimeZoneInfo.Local); + throw new ArgumentException (dateTime Kind value is Utc but sourceTimeZone is not Utc); if (sourceTimeZone.IsInvalidTime (dateTime)) throw new ArgumentException (dateTime parameter is an invalid time); @@ -236,7 +233,7 @@ if (dateTime.Kind == DateTimeKind.Utc) return dateTime; - if (dateTime.Kind == DateTimeKind.Local) + if (dateTime.Kind == DateTimeKind.Local sourceTimeZone == TimeZoneInfo.Utc) return ConvertTimeToUtc (dateTime); if (sourceTimeZone.IsAmbiguousTime (dateTime) || !sourceTimeZone.IsDaylightSavingTime (dateTime)) http://www.nabble.com/file/p18658416/TimeZoneInfo.cs.diff TimeZoneInfo.cs.diff KevinReay wrote: Hi everyone, I think I may have spotted a bug in the System.TimeZoneInfo.ConvertTimeToUtc(DateTime, TimeZoneInfo) method. I could, of course, be wrong (clue-stick appreciated!). The following check appears to be wrong: if (dateTime.Kind == DateTimeKind.Local sourceTimeZone != TimeZoneInfo.Local) throw new ArgumentException (Kind propery of dateTime is Local but the sourceTimeZone does not equal TimeZoneInfo.Local); Shouldn't this code only check that if sourceTimeZone == TimeZoneInfo.Utc, as the sourceTimeZone could be represent a local timezone while still not being equal to TimeZoneInfo.Local (The system's local timezone)? As an example, the following code runs as expected under .Net/Windows: TimeZoneInfo _SpecifiedTimezone = TimeZoneInfo.FindSystemTimeZoneById(SpecifiedTimeZone); _NewMeeting.DateBegin = TimeZoneInfo.ConvertTimeToUtc(DateTime.Parse(SpecifiedDate), _SpecifiedTimezone); But fails with the following exception when run under mono: Kind propery of dateTime is Local but the sourceTimeZone does not equal TimeZoneInfo.Local Thanks, Kevin -- View this message in context: http://www.nabble.com/Possible-bug-in-ConvertTimeToUtc%28DateTime%2C-TimeZoneInfo%29--tp18648344p18658416.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] possible bug: MonoDevelop running on Windows
Hi, I'm new on the Mono World and I trying to use MonoDevelop, and I build entirely with gmcs. Below showed error when a try to run MonoDevelop: === E:\Mono Projects\monodevelop-0.13.1\Core\srcmono --debug build\bin\MonoDevelop.exe -ipc-tcp Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initial izer for MonoDevelop.Core.PropertyService --- System.ArgumentNullException: Argument cannot be null Parameter name: path1 at System.IO.Path.Combine (System.String path1, System.String path2) [0x000df] in C:\cygwin\tmp\scratch\mono-1.2.3.50\mcs\class\corlib\System.IO\Path.cs:138 at MonoDevelop.Core.PropertyService..cctor () [0x0] --- End of inner exception stack trace --- at 0x0 unknown method at MonoDevelop.Core.AddIns.Setup.SetupService.get_BinPath () [0x0] at MonoDevelop.Core.AddIns.Setup.SetupService.get_RootAddinPath () [0x0] at MonoDevelop.Core.AddIns.Setup.SetupService.Initialize (System.String[] addInDirs, Boolean ignoreDefaultPath) [0x0] at MonoDevelop.Core.AddIns.AddInService.Initialize () [0x0] E:\Mono Projects\monodevelop-0.13.1\Core\src === PS: The path C:\cygwin don't exists. Thank you very much.___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] possible bug with FileSystemWatcher
On 03/10/06, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, I'm trying to monitor /dev using the FileSystemWatcher however my app seems to hang at the point when i call watcher.IncludeSubdirectories = true without that line the code runs fine. Monitoring /tmp with that option turned on does work... Also if i try running the code with MONO_MANAGED_WATCHER=1 then I get the following error message continuously appearing: One of the problems that we ran into while trying to debug this problem is that it seems that /dev/fd/6 is a symlink that points to a non-existant file called inotify The file is special in that if you access /dev/fd/6 you get a valid file handle, reporting that its a directory, but if you try to follow the symlink you get a failure (because inotify does not exist). We are quite puzzled about this, not sure quite what to do, because Mono determines that we have a directory, and when we look for it, it tells us that its not a directory. Miguel. I dont have /dev/fd/6 on my system but I guess there must be other special dev files... Really I'm just interested in monitoring /dev/dvb but since the FSW cant handle monitoring a directory that might not currently exist I have to monitor /dev recursively. I guess I'll have to just use two watchers one for /dev and one for /dev/dvb when it appears, which is a bit lame. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] possible bug with FileSystemWatcher
On 04/10/06, Alex Mac [EMAIL PROTECTED] wrote: On 03/10/06, Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, I'm trying to monitor /dev using the FileSystemWatcher however my app seems to hang at the point when i call watcher.IncludeSubdirectories = true without that line the code runs fine. Monitoring /tmp with that option turned on does work... Also if i try running the code with MONO_MANAGED_WATCHER=1 then I get the following error message continuously appearing: One of the problems that we ran into while trying to debug this problem is that it seems that /dev/fd/6 is a symlink that points to a non-existant file called inotify The file is special in that if you access /dev/fd/6 you get a valid file handle, reporting that its a directory, but if you try to follow the symlink you get a failure (because inotify does not exist). We are quite puzzled about this, not sure quite what to do, because Mono determines that we have a directory, and when we look for it, it tells us that its not a directory. Miguel. I dont have /dev/fd/6 on my system but I guess there must be other special dev files... Really I'm just interested in monitoring /dev/dvb but since the FSW cant handle monitoring a directory that might not currently exist I have to monitor /dev recursively. I guess I'll have to just use two watchers one for /dev and one for /dev/dvb when it appears, which is a bit lame. Hmm, although that does work I guess there's no guarantee that the second FSW will be created in time to catch the first events to come from /dev/dvb Monitoring /dev recursively would be preferable ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] possible bug with FileSystemWatcher
Hello, I dont have /dev/fd/6 on my system but I guess there must be other special dev files... The file only exists during the time that inotify is being setup on /dev/fd, thats why you have not seen it. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] possible bug with FileSystemWatcher
I'm trying to monitor /dev using the FileSystemWatcher however my app
seems to hang at the point when i call watcher.IncludeSubdirectories
= true without that line the code runs fine. Monitoring /tmp with
that option turned on does work...
Also if i try running the code with MONO_MANAGED_WATCHER=1 then I
get the following error message continuously appearing:
** Message: Unknown errno: Too many levels of symbolic links
FYI I'm running ubuntu edgy with their latest version of mono as of today.
Here is the app:
using System;
using System.IO;
namespace test
{
public class foo
{
public static void delete_handler (object sender,
FileSystemEventArgs e)
{
Console.WriteLine(delete_handler: + e.Name + , +
e.FullPath);
}
public static void changed_handler (object sender,
FileSystemEventArgs e)
{
Console.WriteLine(changed_handler: + e.Name + , +
e.FullPath);
}
public static void created_handler (object sender,
FileSystemEventArgs e)
{
Console.WriteLine(created_handler: + e.Name + , +
e.FullPath);
}
public static void renamed_handler (object sender,
RenamedEventArgs e)
{
Console.WriteLine(renamed_handler: + e.Name + , +
e.FullPath);
}
public static void Main(string[] args)
{
Console.WriteLine(Testing FileSystemWatcher...);
FileSystemWatcher watcher = new
FileSystemWatcher(/dev);
watcher.EnableRaisingEvents = true;
watcher.IncludeSubdirectories = true;
watcher.Deleted += new
FileSystemEventHandler(delete_handler);
watcher.Changed += new
FileSystemEventHandler(changed_handler);
watcher.Created += new
FileSystemEventHandler(created_handler);
watcher.Renamed += new
RenamedEventHandler(renamed_handler);
Console.WriteLine(waiting...);
Console.ReadLine();
}
}
}
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] possible bug with FileSystemWatcher
On Tue, 2006-10-03 at 20:51 +0100, Alex Mac wrote: I'm trying to monitor /dev using the FileSystemWatcher however my app seems to hang at the point when i call watcher.IncludeSubdirectories = true without that line the code runs fine. Monitoring /tmp with that option turned on does work... What version of mono are you using? I get an error when it tries to watch a directory for which my user does not have permission. -Gonzalo ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] possible bug with FileSystemWatcher
On 03/10/06, Gonzalo Paniagua Javier [EMAIL PROTECTED] wrote: On Tue, 2006-10-03 at 20:51 +0100, Alex Mac wrote: I'm trying to monitor /dev using the FileSystemWatcher however my app seems to hang at the point when i call watcher.IncludeSubdirectories = true without that line the code runs fine. Monitoring /tmp with that option turned on does work... What version of mono are you using? I get an error when it tries to watch a directory for which my user does not have permission. -Gonzalo I'm using the latest version (1.1.17.1-1ubuntu6) My user account has read/execute permissions on all of /dev except for some sub dirs. Is there not a way to monitor a dir recursively but only the dirs i can read? Anyway the code just hangs rather than giving some kind of useful error... ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] possible bug with FileSystemWatcher
Alex Mac wrote: I'm trying to monitor /dev using the FileSystemWatcher however my app seems to hang at the point when i call watcher.IncludeSubdirectories = true without that line the code runs fine. Monitoring /tmp with that option turned on does work... Also if i try running the code with MONO_MANAGED_WATCHER=1 then I get the following error message continuously appearing: ** Message: Unknown errno: Too many levels of symbolic links The message is probably harmless. It gets emitted because ELOOP has no Win32 error code. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] possible bug with FileSystemWatcher
On 03/10/06, Robert Jordan [EMAIL PROTECTED] wrote: Alex Mac wrote: I'm trying to monitor /dev using the FileSystemWatcher however my app seems to hang at the point when i call watcher.IncludeSubdirectories = true without that line the code runs fine. Monitoring /tmp with that option turned on does work... Also if i try running the code with MONO_MANAGED_WATCHER=1 then I get the following error message continuously appearing: ** Message: Unknown errno: Too many levels of symbolic links The message is probably harmless. It gets emitted because ELOOP has no Win32 error code. Robert It might be harmless but mono seems to be stuck in a loop emitting that message continuously which can't be right. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] possible bug with FileSystemWatcher
Hello, I'm trying to monitor /dev using the FileSystemWatcher however my app seems to hang at the point when i call watcher.IncludeSubdirectories = true without that line the code runs fine. Monitoring /tmp with that option turned on does work... Also if i try running the code with MONO_MANAGED_WATCHER=1 then I get the following error message continuously appearing: One of the problems that we ran into while trying to debug this problem is that it seems that /dev/fd/6 is a symlink that points to a non-existant file called inotify The file is special in that if you access /dev/fd/6 you get a valid file handle, reporting that its a directory, but if you try to follow the symlink you get a failure (because inotify does not exist). We are quite puzzled about this, not sure quite what to do, because Mono determines that we have a directory, and when we look for it, it tells us that its not a directory. Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Possible Bug?
Consider the following class declaration.
internal class PluginBase {
private string _path;
public PluginBase( string path ) {
_path = path;
}
public instanceType CreateInstanceinstanceType(
string assemblyidentifier,
string typeidentifier ) where instanceType : class
where instanceType : class {
Assembly assembly;
assembly = Assembly.Load( AssemblyName.GetAssemblyName( _path ) );
if( assembly != null ) {
return (assembly.CreateInstance( typeidentifier ))
as instanceType;
}
}
}
}
This code compiles in .NET
When I attempt to compile with Mono from SVN I get the following error.
/Users/cgross/Desktop/projects/oop-using-net-patterns/src/Chap05.TranslationDefinitions/definitions.cs(33)
error CS0077: The as operator should be used with a reference type only
(instanceType is a value type)
Should this not compile?
Thanks
Christian Gross
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Possible bug in FontInfo.cs (Possible fix included)
I was trying out a webcontrol (skmMenu from www.gotdotnet.com) and received an IndexOutOfRangeException in FontInfo's get_Name method. The current code is: if(Names!=null) return Names[0]; return String.Empty; It seems to me that this should be: if(Names!=null Names.Length0) return Names[0]; return String.Empty; From the get_Names method it seems that the current code would fail when the ViewState's FontInfoNames element contains an empty (non-null) array. I do not know too much about the internals of .NET, so I am posting this here for comments. Thanks, Rich Alimi ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Possible bug in FontInfo.cs (Possible fix included)
El vie, 19-09-2003 a las 19:46, Rich Alimi escribió: [...] I do not know too much about the internals of .NET, so I am posting this here for comments. You were right. I've just fixed it in CVS. Thanks. -Gonzalo. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Possible bug in XmlDocument
Hello!
I think I've found a bug in function RemoveChild from
XmlNode. I don't know if it really is a bug because i hadn't
enough time to test it on ms .net.
The problem happens when you delete the las child node of a node
that has more than one child (i've test with 3), and then you
try to save it contents.
The sources of the example are attached.
Bye!
--
·
· .--. _·
·|o_o | Daniel Pecos Martínez/ \ ·
·|:_/ | IRC Name: zeyen | () | ·
· // \ \| \_/ ·
· (| | ) Web: www.netpecos.org\ ·
· /'\_ _/`\ \·
· \___)=(___/ Linux User: #175518 debian ·
·
only available on a need to know basis
using System;
using System.Xml;
namespace p {
class test {
public static void Main (string [] args) {
XmlDocument a = new XmlDocument();
a.Load(test.xml);
XmlNode n1 = a.FirstChild;
XmlNode n2 = n1.FirstChild.NextSibling.NextSibling;
n1.RemoveChild(n2);
a.Save(Console.Out);
}
}
}
test
h1h1/h1
h2h1/h2
h3h1/h3
/test
pgp0.pgp
Description: PGP signature
