From: Robert Roessler <roessler@rftp.com>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: Christophe TROESTLER <Christophe.Troestler@umh.ac.be>,
"O'Caml Mailing List" <caml-list@inria.fr>
Subject: Re: [Caml-list] [WISH] Unix.fstat and symlinks for win32
Date: Wed, 02 Feb 2005 14:08:48 -0800 [thread overview]
Message-ID: <42014F70.9040509@rftp.com> (raw)
In-Reply-To: <20050202095420.GA8040@yquem.inria.fr>
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
prev parent reply other threads:[~2005-02-02 22:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-01 10:07 Christophe TROESTLER
2005-02-01 11:39 ` [Caml-list] " Marcin 'Qrczak' Kowalczyk
2005-02-01 12:38 ` Christophe TROESTLER
2005-02-01 14:19 ` Igor Pechtchanski
2005-02-02 9:54 ` Xavier Leroy
2005-02-02 12:52 ` Christophe TROESTLER
2005-02-02 15:08 ` Christopher A. Watford
2005-02-02 22:08 ` Robert Roessler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42014F70.9040509@rftp.com \
--to=roessler@rftp.com \
--cc=Christophe.Troestler@umh.ac.be \
--cc=Xavier.Leroy@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox