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

[Jérôme De Cuyper]

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/20101213/4134ee3e/attachment.html