[Mono-dev] Add constants for directory and file max length name? (on windows)

[Jérôme De Cuyper]

Did I get it completely wrong in my last message?

Thanks.

On Mon, Dec 13, 2010 at 11:25 PM, Jérôme De Cuyper <
jerome.decuyper at gmail.com> wrote:

> If I understand correctly, I should not be checking for this on the
> framework level but instead on the layer below it?
> Somehow I should catch the syscall errors and then throw a .NET exception,
> is that correct?
>
>
> On Mon, Dec 13, 2010 at 10:17 PM, Rodrigo Kumpera <kumpera at gmail.com>wrote:
>
>> Can't we check for syscall errors instead?
>>
>>
>> On Mon, Dec 13, 2010 at 10:43 PM, Jérôme De Cuyper <
>> jerome.decuyper at gmail.com> wrote:
>>
>>> I'm working on the following bug:
>>> https://bugzilla.novell.com/show_bug.cgi?id=<https://bugzilla.novell.com/show_bug.cgi?id=383909>
>>> 383909 <https://bugzilla.novell.com/show_bug.cgi?id=383909>
>>>
>>> <https://bugzilla.novell.com/show_bug.cgi?id=383909>On a windows box,
>>> the size of the name of file may not be longer than 260 and the size of the
>>> name of a directory must be smaller than 248 chars. I was thinking about
>>> adding a constant to the Path.cs file and then using it to apply
>>> restrictions when necessary (inside DirectoryInfo's constructor for
>>> instance). But I'm not sure that adding those constants is the best
>>> cross-platform way to handle this. Maybe it's is enough to use hard-coded
>>> values inside a "IsRunningOnWindows" conditional. Any thoughts?
>>>
>>> Jerome.
>>>
>>>
>>>
>>>
>>> On Mon, Dec 13, 2010 at 6:08 PM, Charles Strahan <
>>> charles.c.strahan at gmail.com> wrote:
>>>
>>>> Jon,
>>>>
>>>> If I understand correctly, we'd have two options for using DLLImport:
>>>>
>>>>  1.) Emit classes at runtime, containing the necessary native
>>>> function adorned with the DLLImport attribute.
>>>>  2.) Use DLLImport/PInvoke to provide access to
>>>> dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
>>>> load DLLs and invoke their functions.
>>>>
>>>> Is this correct? Option #1 seems relatively feasible, although we
>>>> would give up the ability to use our RubyFFI implementation where
>>>> Reflection.Emit is not available; Option #2 seems rather daunting.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Charles
>>>>
>>>> >On Thu, 2010-08-19 at 10:35 -0700, Ryan Riley wrote:
>>>> >> Has anyone created or investigated Mono support for libffi?
>>>> >
>>>> >Once upon a time, Mono used libffi directly.  It was removed in r724
>>>> >(git SHA1 ID d0cd6059c1b2edad12eb67cb8e64b3cd187be1b1) on 2001-09-05
>>>> >(and earlier).  Unfortunately, the commit message is useless, but iirc
>>>> >the reason for removing it was because it was significantly slower than
>>>> >what Mono could do itself.
>>>> >
>>>> >> I'd like to contribute this to help support Ruby-FFI for IronRuby.
>>>> >
>>>> >I imagine IronRuby doesn't require it's own FFI, it would just use the
>>>> >usual .NET FFI of DllImport, no?
>>>> >
>>>> >As for supporting Ruby-FFI, perhaps you can extend the existing Mono
>>>> FFI
>>>> >support to support Ruby?  I don't know what would be involved...
>>>> >
>>>> > - Jon
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20101214/65e04a4c/attachment.html