[Mono-dev] Add constants for directory and file max length name? (on windows)
Jérôme De Cuyper
jerome.decuyper at gmail.com
Tue Dec 14 00:25:33 EST 2010
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:
>> 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?
>> On Mon, Dec 13, 2010 at 6:08 PM, Charles Strahan <
>> charles.c.strahan at gmail.com> wrote:
>>> 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.
>>> >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
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list