Browse thread
[WISH] Unix.fstat and symlinks for win32
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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