Version française
Home     About     Download     Resources     Contact us    
Browse thread
[WISH] Unix.fstat and symlinks for win32
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Robert Roessler <roessler@r...>
Subject: Re: [Caml-list] [WISH] Unix.fstat and symlinks for win32
Xavier Leroy wrote:

>>Just a small note to tell that I think it would be nice to have
>>support for Unix.*stat on win32.  Not all characteristics may make
>>sense but [file_kind], [st_size], [st_perm], [st_*time] do.
> 
> 
> I don't quite understand your question: Unix.stat is implemented under
> Windows (building on the _stati64() function provided by the MS C library)
> and sets the fields you mention to reasonable values.
> 
> Still under Windows (native Windows, not Cygwin), Unix.lstat behaves
> like Unix.stat and Unix.fstat is not implemented.  (I'm not even sure
> the latter is implementable at all with the Win32 API.)

Actually, not only is [LargeFile.]fstat implementable under Win32, but 
so are [LargeFile.]ftruncate... not to mention that pause and alarm 
*could* be done also, but possibly not as cleanly as the former four.

Details on the above:

ftruncate and LargeFile.ftruncate would work on ALL Win32 platforms, 
using ::SetFilePointer and ::SetEndOfFile (the "::" is what I use to 
distinguish API calls from app or C runtime calls).

fstat and LargeFile.fstat would (according the .NET 2003 C Run-Time 
Library Reference) work on all Win32 platforms EXCEPT Windows 95, 
using _fstati64.  Note that one needs to examine the actual sys/stat.h 
file to see that "_S_IFIFO" is used to denote pipes.

alarm could be done with ::SetTimer, and even be made to work in 
concert with pause, which could use (pick your favorite variant) some 
form of ::[Msg]WaitFor{Single,Multiple}Object[s]... but you would need 
to take some care WRT Windows event processing. :)

As for the ".lnk" files, they don't really correspond with *nix 
notions of either "hard" or "symbolic" links, so attempts at mapping 
them are bound to disappoint some (if not all).

My USD 0.02.

Robert Roessler
robertr@rftp.com
http://www.rftp.com