Il 31/10/2012 14:45, Jonas Maebe ha scritto:
On 31 Oct 2012, at 14:35, Giuliano Colla wrote:
Understood, thank you. But shouldn't it be the other way around, i.e.
one should explicitly request an exclusive lock?
No, that is how the behaviour of this function is defined. Looking at
the documentation, is seems that file locking for Unix was already
implemented in FPC 2.4.0 though, so maybe that won't be the problem
after all.
Well, from the way Delphi File Mode are defined since the dawn of times,
if you don't or fmWrite with anything, the default behavior is to open
in fmShareCompat mode (=0), a legacy DOS mode tied to the long time dead
FCB inherited from CP/1, which, to my knowledge, doesn't grant an
exclusive lock, and which has no Unix equivalent. IMHO opinion it would
be more reasonable to map this mode to a plain non-locking mode, in Unix
environment.
but if it doesn't it's a Delphi bug, I'd say. What are exceptions
there for, if not for telling you that what you requested cannot be
done?
There are multiple ways to indicate a failure. Exceptions are a very
expensive way for doing so, and generally should only be used in cases
that are truly exceptional and/or indicate a fatal error. In other
cases, using a special return value is generally much more appropriate.
My bad. I hadn't realized that low level file operation such as FileOpen
and FileCreate do not raise an exception on failure. I seldom use them,
and only in connection with physical devices, where I always take care
to verify the existence before attempting to read or write. So I just
relied on a useless try-except construct.
It's very unlikely that such a failure would permit a program to
continue running, I'd call it a fatal error, so an exception would be
welcome, but that's life...
Giuliano
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
