re: system:file-size

Found it.

with-open-file tells me

<<
The process cannot access the file because it is being used by 
another process.(32).
 >>






>Date: Sat, 04 Feb 2006 18:48:40 +0100
>To: lisp-hug@lispworks.com
>From: Kristoffer Kvello <kristoffer.kvello@mindless.com>
>Subject: system:file-size
>
>Hello,
>
>I've just had system:file-size return NIL when applied to an 
>existing file of 82K. I cannot find any documentation of the 
>function, but since it's exported I assume it's meant to be 
>used.  Does anyone know what NIL in this situation means? (LWW 4.3, 
>all patches).
>
>Thanks.
>
>
>Kristoffer

Re: system:file-size

Kristoffer Kvello <kristoffer.kvello@mindless.com> writes:

> with-open-file tells me
>
> <<
> The process cannot access the file because it is being used by 
> another process.(32).
>>>

But having a file in use shouldn't prevent lw from reading its size,
should it?

It doesn't on LWL 4.4.6, at least.  Calling it on my running image:

USER> (system:file-size "/usr/local/lib/lw44/tty-lispworks")
20250652

-- 
Mvh/Regards
Peder O. Klingenberg
Netfonds ASA

Re: system:file-size

pok@netfonds.no (Peder O. Klingenberg) writes:

> But having a file in use shouldn't prevent lw from reading its size,
> should it?

One word says it all: Windows.
-- 
  (espen)

Re: system:file-size

On Mon, 06 Feb 2006 10:04:47 +0100, Espen Vestre <ev@netfonds.no> wrote:

> pok@netfonds.no (Peder O. Klingenberg) writes:
>
>> But having a file in use shouldn't prevent lw from reading its
>> size, should it?
>
> One word says it all: Windows.

While Windows bashing is always fun, I think the explanation is a bit
too simple in this case.  I can open a file for writing in one LWW
image and SYS:FILE-SIZE reports the correct file size in another
image.  I can add lines to the file in the first image, and
SYS:FILE-SIZE still reports the correct (updated) size in the second
image.  The same works with a .DOC file in use by Microsoft Word.

I would assume that in the OP's case another process has opened the
file with dwShareMode being 0 (zero).  In that case the behaviour he
sees is on purpose.

Cheers,
Edi.

Re: system:file-size

Edi Weitz <edi@agharta.de> writes:

> I would assume that in the OP's case another process has opened the
> file with dwShareMode being 0 (zero).  In that case the behaviour he
> sees is on purpose.

Well for a unix head it still seems utterly weird that you still can't
use something like stat to retrieve info on the file.

In addition, I've seen files opened exclusively in cases where there
seemed to be absolutely no reason for it. I thought it was Windows
itself or one of the standard programs that were responsible for that
nutty behaviour, but the last time was quite a while ago (hmm, maybe
it even was on Win 98...), so I won't bet on that.

-- 
  (espen)

Re: system:file-size

On Mon, 06 Feb 2006 13:18:03 +0100, Espen Vestre <ev@netfonds.no> wrote:

> Well for a unix head it still seems utterly weird that you still
> can't use something like stat to retrieve info on the file.

I don't want to argue in favor of Windows but one /could/ say that it
just adds another option you don't have on Unix out of the box - a
completely exclusive lock in addition to the usual write lock.

(Contrived example: Process A is writing to a file and process B is
trying to get the file's size.  If data from process A is in the cache
and hasn't been flushed yet, there'll be situations where process B
gets the wrong size.  If for whatever reason you, as the author of
process A, think this is intolerable, you can prevent process B from
reading the size, effectively implementing a policy of "it is better
to have no data than to have wrong data."  How would you do that on
Unix?)

The problem of course is that this feature might be mis-used by badly
written applications - see below.

> In addition, I've seen files opened exclusively in cases where there
> seemed to be absolutely no reason for it. I thought it was Windows
> itself or one of the standard programs that were responsible for
> that nutty behaviour, but the last time was quite a while ago (hmm,
> maybe it even was on Win 98...), so I won't bet on that.