• Arcane Jill (11/11) Jul 21 2004 On the Windows platform:
• Stewart Gordon (36/48) Jul 21 2004 In accordance with the documentation.
• Arcane Jill (10/21) Jul 21 2004 Whoops. Should have said:
• Burton Radons (5/36) Jul 21 2004 Yes. "If the file does not exist, it is created." There's nothing
• Regan Heath (23/67) Jul 21 2004 I suggested these a little while back:
• Derek Parnell (50/129) Jul 21 2004 Hmmmm...this got me a-thinkin'...
• Regan Heath (6/135) Jul 21 2004 Excellent work. I believe I will pilfer this list for a File
• Stewart Gordon (35/70) Jul 22 2004 By your system, RA together means that reads start from the beginning,
• Regan Heath (23/92) Jul 22 2004 Or.. (MSDN fopen docs)
• Stewart Gordon (23/70) Jul 22 2004 Yes, we could have append as a distinct writing mode, rather than merely...
• Regan Heath (17/83) Jul 22 2004 Why not U?
• Stewart Gordon (18/47) Jul 23 2004 By that, I actually meant even if U is not also specified.
• Regan Heath (10/52) Jul 23 2004 Correct.. if it's not atomic you have to write something to the file,
• Stewart Gordon (23/29) Jul 26 2004
• Regan Heath (15/39) Jul 26 2004 It's a mine field all right I believe you have to use a well placed slee...
• Derek (21/93) Jul 22 2004 Yes. So...? Though I'm not sure about needing two cursors. One could hav...
• Ben Hinkle (7/18) Jul 21 2004 To get the behavior Jill describes on Windows, change the two occurrence...
• Andrew Edwards (5/22) Jul 21 2004 You know! I remember when this feature operated the way you now expect
• Andrew Edwards (3/28) Jul 21 2004 As a matter of fact, here's the post that prompted the change:
• Andrew Edwards (4/8) Jul 21 2004 Teaches me for opening my mouth too fast. He was talking about

Arcane Jill <Arcane_member pathlink.com> writes:

On the Windows platform:








creates the file "foo", does not throw any kind of exception, and then carries
on executing as though everything were hunky dory.

This is currently a very good reason not to use std.stream.File

Arcane Jill

Stewart Gordon <smjg_1998 yahoo.com> writes:

Arcane Jill wrote:
 On the Windows platform:
 






 
 creates the file "foo", does not throw any kind of exception, and then carries
 on executing as though everything were hunky dory.

In accordance with the documentation.

----------
this()
this(char[] filename)
this(char[] filename, FileMode mode)
     Create the stream with no open file, an open file in read and write 
mode, or an open file with explicit file mode. mode, if given, is a 
combination of FileMode.In (indicating a file that can be read) and 
FileMode.Out (indicating a file that can be written). If the file does 
not exist, it is created.
----------

After all, your code does say "new File"!  Even though that isn't what 
it really means!

 This is currently a very good reason not to use std.stream.File

Yes, the whole File class could be more clearly defined.  At the moment, 
it seems you're meant to manually call std.file.exists first.  Chances 
are this isn't part of the normal program logic....

My idea would probably be something like

enum FILE_MODE {
	IN                    = 0b000001,
	OUT                   = 0b000010,
	CREATE_IF_NONEXISTENT = 0b000100,
	NEW_FILE              = 0b001100,    /*!< create new file,
	                                      prevent overwrite */
	OVERWRITE             = 0b001000,    /*!< create new file,
	                                      overwrite if necessary */
	APPEND                = 0b010000,    //!< start pointer at end
	EXCLUSIVE             = 0b100000     /*!< lock for exclusive
  	                                      access, if that follows */
}

Obviously some combinations don't make sense....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.

Arcane Jill <Arcane_member pathlink.com> writes:

In article <cdlpci$2ma4$1 digitaldaemon.com>, Stewart Gordon says...
Arcane Jill wrote:
 On the Windows platform:
 








Whoops. Should have said:

import std.stream;






Please observe the FileMode.In parameter

 creates the file "foo", does not throw any kind of exception, and then carries
 on executing as though everything were hunky dory.


Is /this/ in accordance with the documentation?

Arcane Jill

Burton Radons <burton-radons shaw.ca> writes:

Arcane Jill wrote:
 In article <cdlpci$2ma4$1 digitaldaemon.com>, Stewart Gordon says...
 
Arcane Jill wrote:

On the Windows platform:









 
 
 Whoops. Should have said:
 
 import std.stream;
 




 
 Please observe the FileMode.In parameter
 
 
creates the file "foo", does not throw any kind of exception, and then carries
on executing as though everything were hunky dory.


 
 
 Is /this/ in accordance with the documentation?

Yes.  "If the file does not exist, it is created."  There's nothing 
about examining the mode parameter for how to behave; it only modifies 
what operations can be performed on the stream.

I do think the API's incorrectly designed, but it's not a bug.

Regan Heath <regan netwin.co.nz> writes:

On Wed, 21 Jul 2004 14:00:01 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
wrote:
 Arcane Jill wrote:
 On the Windows platform:








 creates the file "foo", does not throw any kind of exception, and then 
 carries
 on executing as though everything were hunky dory.

 In accordance with the documentation.

 ----------
 this()
 this(char[] filename)
 this(char[] filename, FileMode mode)
      Create the stream with no open file, an open file in read and write 
 mode, or an open file with explicit file mode. mode, if given, is a 
 combination of FileMode.In (indicating a file that can be read) and 
 FileMode.Out (indicating a file that can be written). If the file does 
 not exist, it is created.
 ----------

 After all, your code does say "new File"!  Even though that isn't what 
 it really means!

 This is currently a very good reason not to use std.stream.File

 Yes, the whole File class could be more clearly defined.  At the moment, 
 it seems you're meant to manually call std.file.exists first.  Chances 
 are this isn't part of the normal program logic....

 My idea would probably be something like

 enum FILE_MODE {
 	IN                    = 0b000001,
 	OUT                   = 0b000010,
 	CREATE_IF_NONEXISTENT = 0b000100,
 	NEW_FILE              = 0b001100,    /*!< create new file,
 	                                      prevent overwrite */
 	OVERWRITE             = 0b001000,    /*!< create new file,
 	                                      overwrite if necessary */
 	APPEND                = 0b010000,    //!< start pointer at end
 	EXCLUSIVE             = 0b100000     /*!< lock for exclusive
   	                                      access, if that follows */
 }

 Obviously some combinations don't make sense....


I suggested these a little while back:

READ
WRITE
CREATE
APPEND
NEW

allowing:

"r"  - READ        - read, fails if file does not exist.
"w"  - CREATE      - write, overwrite existing.
"a"  - APPEND      - write, create if not exist.
"r+" - READ|WRITE  - read, write, fails if file does not exist.
"w+" - READ|CREATE - read, write, overwrite existing.
"a+" - READ|APPEND - read, append, create if not exist.
""   - WRITE|NEW   - write, fail if file exist.

to mirror fopen capability _and_ add new WRITE|NEW capability.


I would extend File creating LockedFile and/or add a LockFile class to 
handle file locking as it is done differently on the various *NIX 
operating systems.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Derek Parnell <derek psych.ward> writes:

On Thu, 22 Jul 2004 12:00:32 +1200, Regan Heath wrote:

 On Wed, 21 Jul 2004 14:00:01 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
 wrote:
 Arcane Jill wrote:
 On the Windows platform:








 creates the file "foo", does not throw any kind of exception, and then 
 carries
 on executing as though everything were hunky dory.

 In accordance with the documentation.

 ----------
 this()
 this(char[] filename)
 this(char[] filename, FileMode mode)
      Create the stream with no open file, an open file in read and write 
 mode, or an open file with explicit file mode. mode, if given, is a 
 combination of FileMode.In (indicating a file that can be read) and 
 FileMode.Out (indicating a file that can be written). If the file does 
 not exist, it is created.
 ----------

 After all, your code does say "new File"!  Even though that isn't what 
 it really means!

 This is currently a very good reason not to use std.stream.File

 Yes, the whole File class could be more clearly defined.  At the moment, 
 it seems you're meant to manually call std.file.exists first.  Chances 
 are this isn't part of the normal program logic....

 My idea would probably be something like

 enum FILE_MODE {
 	IN                    = 0b000001,
 	OUT                   = 0b000010,
 	CREATE_IF_NONEXISTENT = 0b000100,
 	NEW_FILE              = 0b001100,    /*!< create new file,
 	                                      prevent overwrite */
 	OVERWRITE             = 0b001000,    /*!< create new file,
 	                                      overwrite if necessary */
 	APPEND                = 0b010000,    //!< start pointer at end
 	EXCLUSIVE             = 0b100000     /*!< lock for exclusive
   	                                      access, if that follows */
 }

 Obviously some combinations don't make sense....

 
 I suggested these a little while back:
 
 READ
 WRITE
 CREATE
 APPEND
 NEW
 
 allowing:
 
 "r"  - READ        - read, fails if file does not exist.
 "w"  - CREATE      - write, overwrite existing.
 "a"  - APPEND      - write, create if not exist.
 "r+" - READ|WRITE  - read, write, fails if file does not exist.
 "w+" - READ|CREATE - read, write, overwrite existing.
 "a+" - READ|APPEND - read, append, create if not exist.
 ""   - WRITE|NEW   - write, fail if file exist.
 
 to mirror fopen capability _and_ add new WRITE|NEW capability.
 
 I would extend File creating LockedFile and/or add a LockFile class to 
 handle file locking as it is done differently on the various *NIX 
 operating systems.
 

Hmmmm...this got me a-thinkin'...

I came up with this...
The open() routine seems to controls four aspects:

  Access: Read, Write, Both, Neither
  File-Exists action: Use, Overwrite, Fail
  File-Not-Exists action: Create, Fail
  Initial Seek: Start-of-File (normal), End-of-File (append)

This leads to 48 different combinations, some of which are not useful (eg.
neither read nor write, fails if exists and if not-exists, read starting
from end of file, etc...). So after removing the useless combinations, we
are left with 20 possible ones.

I've devised six codes that encompass these combinations:
R : read access from start of file
W : write access from start of file
A : write access from end of file
U : use existing file
O : overwrite existing file
C : create non-existing file

So the useful combinations that either open a file or fail are (I've also
show Regan's equivalent codes) ...

RWUC      - read, write, use existing, create if not existing.
RAUC "a+" - read, append (to existing), create if not exist.
RWOC "w+" - read, write, overwrite existing(, create if not existing).
RWU  "r+" - read, write, fails if file does not exist.
RAU       - read, append to existing, fail if not exist.
RWC       - read, write, fail if exists, create if not existing.
RWO       - read, write, overwrite if exists, fail if not existing.
RAO       - read, append if exists, fail if not existing.
WUC       - write, use if exists, create if not existing.
AUC  "a"  - write(, append if exists), create if not exist.
WOC  "w"  - write, overwrite existing(, create if not existing).
RUC       - read, use if exists, create if not existing.
ROC       - read, overwrite if exists, create if not existing. (Used to
                 always create an empty file).
RU   "r"  - read, fails if file does not exist.
RC        - read, fail if exists, create if not existing. (Used to create
                 an empty file if it doesn't already exist).
RO        - read, overwrite if exists, fail if not existing. (Used to wipe
                 an existing file).
WU        - write, use if file exists, fail if not existing.
AU        - write, append if file exists, fail if not existing.
WC    ""  - write, fail if file exists(, create if not existing).
WO        - write, overwrite if exists, fail if not existing.(Used to
                 replace an existing file).


Of course, these don't take file locking into account ;-)

-- 
Derek
Melbourne, Australia
22/Jul/04 12:06:49 PM

Regan Heath <regan netwin.co.nz> writes:

On Thu, 22 Jul 2004 12:51:01 +1000, Derek Parnell <derek psych.ward> wrote:
 On Thu, 22 Jul 2004 12:00:32 +1200, Regan Heath wrote:

 On Wed, 21 Jul 2004 14:00:01 +0100, Stewart Gordon <smjg_1998 yahoo.com>
 wrote:
 Arcane Jill wrote:
 On the Windows platform:








 creates the file "foo", does not throw any kind of exception, and then
 carries
 on executing as though everything were hunky dory.

 In accordance with the documentation.

 ----------
 this()
 this(char[] filename)
 this(char[] filename, FileMode mode)
      Create the stream with no open file, an open file in read and 
 write
 mode, or an open file with explicit file mode. mode, if given, is a
 combination of FileMode.In (indicating a file that can be read) and
 FileMode.Out (indicating a file that can be written). If the file does
 not exist, it is created.
 ----------

 After all, your code does say "new File"!  Even though that isn't what
 it really means!

 This is currently a very good reason not to use std.stream.File

 Yes, the whole File class could be more clearly defined.  At the 
 moment,
 it seems you're meant to manually call std.file.exists first.  Chances
 are this isn't part of the normal program logic....

 My idea would probably be something like

 enum FILE_MODE {
 	IN                    = 0b000001,
 	OUT                   = 0b000010,
 	CREATE_IF_NONEXISTENT = 0b000100,
 	NEW_FILE              = 0b001100,    /*!< create new file,
 	                                      prevent overwrite */
 	OVERWRITE             = 0b001000,    /*!< create new file,
 	                                      overwrite if necessary */
 	APPEND                = 0b010000,    //!< start pointer at end
 	EXCLUSIVE             = 0b100000     /*!< lock for exclusive
   	                                      access, if that follows */
 }

 Obviously some combinations don't make sense....

 I suggested these a little while back:

 READ
 WRITE
 CREATE
 APPEND
 NEW

 allowing:

 "r"  - READ        - read, fails if file does not exist.
 "w"  - CREATE      - write, overwrite existing.
 "a"  - APPEND      - write, create if not exist.
 "r+" - READ|WRITE  - read, write, fails if file does not exist.
 "w+" - READ|CREATE - read, write, overwrite existing.
 "a+" - READ|APPEND - read, append, create if not exist.
 ""   - WRITE|NEW   - write, fail if file exist.

 to mirror fopen capability _and_ add new WRITE|NEW capability.

 I would extend File creating LockedFile and/or add a LockFile class to
 handle file locking as it is done differently on the various *NIX
 operating systems.

 Hmmmm...this got me a-thinkin'...

 I came up with this...
 The open() routine seems to controls four aspects:

   Access: Read, Write, Both, Neither
   File-Exists action: Use, Overwrite, Fail
   File-Not-Exists action: Create, Fail
   Initial Seek: Start-of-File (normal), End-of-File (append)

 This leads to 48 different combinations, some of which are not useful 
 (eg.
 neither read nor write, fails if exists and if not-exists, read starting
 from end of file, etc...). So after removing the useless combinations, we
 are left with 20 possible ones.

 I've devised six codes that encompass these combinations:
 R : read access from start of file
 W : write access from start of file
 A : write access from end of file
 U : use existing file
 O : overwrite existing file
 C : create non-existing file

 So the useful combinations that either open a file or fail are (I've also
 show Regan's equivalent codes) ...

 RWUC      - read, write, use existing, create if not existing.
 RAUC "a+" - read, append (to existing), create if not exist.
 RWOC "w+" - read, write, overwrite existing(, create if not existing).
 RWU  "r+" - read, write, fails if file does not exist.
 RAU       - read, append to existing, fail if not exist.
 RWC       - read, write, fail if exists, create if not existing.
 RWO       - read, write, overwrite if exists, fail if not existing.
 RAO       - read, append if exists, fail if not existing.
 WUC       - write, use if exists, create if not existing.
 AUC  "a"  - write(, append if exists), create if not exist.
 WOC  "w"  - write, overwrite existing(, create if not existing).
 RUC       - read, use if exists, create if not existing.
 ROC       - read, overwrite if exists, create if not existing. (Used to
                  always create an empty file).
 RU   "r"  - read, fails if file does not exist.
 RC        - read, fail if exists, create if not existing. (Used to create
                  an empty file if it doesn't already exist).
 RO        - read, overwrite if exists, fail if not existing. (Used to 
 wipe
                  an existing file).
 WU        - write, use if file exists, fail if not existing.
 AU        - write, append if file exists, fail if not existing.
 WC    ""  - write, fail if file exists(, create if not existing).
 WO        - write, overwrite if exists, fail if not existing.(Used to
                  replace an existing file).


 Of course, these don't take file locking into account ;-)

Excellent work. I believe I will pilfer this list for a File 
implementation I am writing.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Stewart Gordon <smjg_1998 yahoo.com> writes:

Derek Parnell wrote:
<snip excessive quote>
 I've devised six codes that encompass these combinations:
 R : read access from start of file
 W : write access from start of file
 A : write access from end of file
 U : use existing file
 O : overwrite existing file
 C : create non-existing file
 
 So the useful combinations that either open a file or fail are (I've also
 show Regan's equivalent codes) ...
 
 RWUC      - read, write, use existing, create if not existing.
 RAUC "a+" - read, append (to existing), create if not exist.

By your system, RA together means that reads start from the beginning, 
and writes from the end.  Which would mean separate read and write 
pointers, and extra functions needed to manipulate them.

  RWOC "w+" - read, write, overwrite existing(, create if not existing).
 RWU  "r+" - read, write, fails if file does not exist.
 RAU       - read, append to existing, fail if not exist.
 RWC       - read, write, fail if exists, create if not existing.
 RWO       - read, write, overwrite if exists, fail if not existing.
 RAO       - read, append if exists, fail if not existing.

That's read, append, overwrite.  Doesn't make sense to me.  Or at least 
it would be redundant as the end of an initially empty file is the same 
as the beginning.

 WUC       - write, use if exists, create if not existing.
 AUC  "a"  - write(, append if exists), create if not exist.
 WOC  "w"  - write, overwrite existing(, create if not existing).
 RUC       - read, use if exists, create if not existing.

Not sure about this one.  To create an empty file if the file isn't 
there, for the benefit of dodgy programs that insist a file exists even 
if it may be empty?

 ROC       - read, overwrite if exists, create if not existing. (Used to
                  always create an empty file).
 RU   "r"  - read, fails if file does not exist.
 RC        - read, fail if exists, create if not existing. (Used to create
                  an empty file if it doesn't already exist).

Correction, to require that a file doesn't already exist, but create it 
as an empty file.  Not sure about this one.

 RO        - read, overwrite if exists, fail if not existing. (Used to wipe
                  an existing file).
 WU        - write, use if file exists, fail if not existing.
 AU        - write, append if file exists, fail if not existing.
 WC    ""  - write, fail if file exists(, create if not existing).
 WO        - write, overwrite if exists, fail if not existing.(Used to
                  replace an existing file).

<snip>

Before I looked through your list, I did my own analysis of your 
enumeration of aspects, which seems the most logical system so far.  I 
separated W and A, so that R simply means read, W simply means write and 
A simply means start at the end.  I came up with 16 combinations as 
making sense:

WUC RWUC WAUC RWAUC WOC RWOC RC RWC RU WU RWU RAU WAU RWAU WO RWO

As you see, I hadn't thought of modes purely to create empty files.  RA, 
WO and RWO make sense but are of questionable value.  To read starting 
from the end does make a bit of sense, if you want to look at the end of 
a file.  But you'd need to seek anyway before you can do anything, so 
there's little point using it.  And you can recreate a file from 
scratch, making sure that you're indeed recreating a file that was 
already there,  but I'm not sure of its practical uses.

But there's little point in validating the combinations to somebody's 
conception of making sense, except for the obvious nonsensicality of UO 
together.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.

Regan Heath <regan netwin.co.nz> writes:

On Thu, 22 Jul 2004 11:56:34 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
wrote:

 Derek Parnell wrote:
 <snip excessive quote>
 I've devised six codes that encompass these combinations:
 R : read access from start of file
 W : write access from start of file
 A : write access from end of file
 U : use existing file
 O : overwrite existing file
 C : create non-existing file

 So the useful combinations that either open a file or fail are (I've 
 also
 show Regan's equivalent codes) ...

 RWUC      - read, write, use existing, create if not existing.
 RAUC "a+" - read, append (to existing), create if not exist.

 By your system, RA together means that reads start from the beginning, 
 and writes from the end.  Which would mean separate read and write 
 pointers, and extra functions needed to manipulate them.

Or.. (MSDN fopen docs)

"When a file is opened with the "a" or "a+" access type, all write 
operations occur at the end of the file. The file pointer can be 
repositioned using fseek or rewind, but is always moved back to the end of 
the file before any write operation is carried out. Thus, existing data 
cannot be overwritten."

  RWOC "w+" - read, write, overwrite existing(, create if not existing).
 RWU  "r+" - read, write, fails if file does not exist.
 RAU       - read, append to existing, fail if not exist.
 RWC       - read, write, fail if exists, create if not existing.
 RWO       - read, write, overwrite if exists, fail if not existing.
 RAO       - read, append if exists, fail if not existing.

 That's read, append, overwrite.  Doesn't make sense to me.  Or at least 
 it would be redundant as the end of an initially empty file is the same 
 as the beginning.

Looks like Derek forgot to prune this one as nonsensical?

 WUC       - write, use if exists, create if not existing.
 AUC  "a"  - write(, append if exists), create if not exist.
 WOC  "w"  - write, overwrite existing(, create if not existing).
 RUC       - read, use if exists, create if not existing.

 Not sure about this one.  To create an empty file if the file isn't 
 there, for the benefit of dodgy programs that insist a file exists even 
 if it may be empty?

Basically it's saying a file should be there (create if not), and I want 
to read anything that's in it if its there. So you're not having to catch 
'file does not exist' exceptions, as in some cases you don't care.

 ROC       - read, overwrite if exists, create if not existing. (Used to
                  always create an empty file).
 RU   "r"  - read, fails if file does not exist.
 RC        - read, fail if exists, create if not existing. (Used to 
 create
                  an empty file if it doesn't already exist).

 Correction, to require that a file doesn't already exist, but create it 
 as an empty file.  Not sure about this one.

Simple file locking, i.e. to lock "foobar.dat" we create "foobat.dat.lock" 
but only if it doesn't already exist (meaning someone has it locked 
already)

 RO        - read, overwrite if exists, fail if not existing. (Used to 
 wipe
                  an existing file).
 WU        - write, use if file exists, fail if not existing.
 AU        - write, append if file exists, fail if not existing.
 WC    ""  - write, fail if file exists(, create if not existing).
 WO        - write, overwrite if exists, fail if not existing.(Used to
                  replace an existing file).

 <snip>

 Before I looked through your list, I did my own analysis of your 
 enumeration of aspects, which seems the most logical system so far.  I 
 separated W and A, so that R simply means read, W simply means write and 
 A simply means start at the end.  I came up with 16 combinations as 
 making sense:

 WUC RWUC WAUC RWAUC WOC RWOC RC RWC RU WU RWU RAU WAU RWAU WO RWO

 As you see, I hadn't thought of modes purely to create empty files.  RA, 
 WO and RWO make sense but are of questionable value.

 To read starting from the end does make a bit of sense, if you want to 
 look at the end of a file.  But you'd need to seek anyway before you can 
 do anything, so there's little point using it.

I don't think it makes much sense to read starting from the end. Like you 
say, you have to seek anyway, why not simply seek from the start to point 
x, instead of from the start to the end and back to point x.

 And you can recreate a file from scratch, making sure that you're indeed 
 recreating a file that was already there,  but I'm not sure of its 
 practical uses.

 But there's little point in validating the combinations to somebody's 
 conception of making sense, except for the obvious nonsensicality of UO 
 together.

True, I think I have demonstrared that by coming up with a few (IMO) 
sensible uses for ones you did not think were sensible?

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Stewart Gordon <smjg_1998 yahoo.com> writes:

Regan Heath wrote:

 On Thu, 22 Jul 2004 11:56:34 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
 wrote:
 
 Derek Parnell wrote:


<snip>
 RAUC "a+" - read, append (to existing), create if not exist.

 
 By your system, RA together means that reads start from the beginning, 
 and writes from the end.  Which would mean separate read and write 
 pointers, and extra functions needed to manipulate them.

 
 Or.. (MSDN fopen docs)
 
 "When a file is opened with the "a" or "a+" access type, all write 
 operations occur at the end of the file. The file pointer can be 
 repositioned using fseek or rewind, but is always moved back to the end 
 of the file before any write operation is carried out. Thus, existing 
 data cannot be overwritten."

Yes, we could have append as a distinct writing mode, rather than merely 
a seek.  In that respect, it would be of use even for O and/or C and not 
U, to force output to be sequential.

As long as it is clear to everyone who uses it....

<snip>
 RAO       - read, append if exists, fail if not existing.

 
 That's read, append, overwrite.  Doesn't make sense to me.  Or at 
 least it would be redundant as the end of an initially empty file is 
 the same as the beginning.

 
 Looks like Derek forgot to prune this one as nonsensical?

Again, I now suppose it makes sense if the aforementioned semantics of 
append are implemented.

 WUC       - write, use if exists, create if not existing.
 AUC  "a"  - write(, append if exists), create if not exist.
 WOC  "w"  - write, overwrite existing(, create if not existing).
 RUC       - read, use if exists, create if not existing.

 Not sure about this one.  To create an empty file if the file isn't 
 there, for the benefit of dodgy programs that insist a file exists 
 even if it may be empty?

 
 Basically it's saying a file should be there (create if not), and I want 
 to read anything that's in it if its there. So you're not having to 
 catch 'file does not exist' exceptions, as in some cases you don't care.

You mean that if the file isn't there, treat it as empty?  This should 
be a third option for File-Not-Exists action.  This would stop empty 
files being created without good cause, and also enable the protocol to 
be used on write-protected media.

 RC        - read, fail if exists, create if not existing. (Used to 
             create an empty file if it doesn't already exist).

 Correction, to require that a file doesn't already exist, but create 
 it as an empty file.  Not sure about this one.

 
 Simple file locking, i.e. to lock "foobar.dat" we create 
 "foobat.dat.lock" but only if it doesn't already exist (meaning someone 
 has it locked already)

Which OSs these days don't have their own built-in concept of file 
locking, which might have the advantage (?) of being automatically 
released if the locking process dies?

<snip>
 True, I think I have demonstrared that by coming up with a few (IMO) 
 sensible uses for ones you did not think were sensible?

I guess so....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.

Regan Heath <regan netwin.co.nz> writes:

On Thu, 22 Jul 2004 13:59:59 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
wrote:
 Regan Heath wrote:

 On Thu, 22 Jul 2004 11:56:34 +0100, Stewart Gordon 
 <smjg_1998 yahoo.com> wrote:

 Derek Parnell wrote:


 <snip>
 RAUC "a+" - read, append (to existing), create if not exist.

 By your system, RA together means that reads start from the beginning, 
 and writes from the end.  Which would mean separate read and write 
 pointers, and extra functions needed to manipulate them.

 Or.. (MSDN fopen docs)

 "When a file is opened with the "a" or "a+" access type, all write 
 operations occur at the end of the file. The file pointer can be 
 repositioned using fseek or rewind, but is always moved back to the end 
 of the file before any write operation is carried out. Thus, existing 
 data cannot be overwritten."

 Yes, we could have append as a distinct writing mode, rather than merely 
 a seek.  In that respect, it would be of use even for O and/or C and not 
 U, to force output to be sequential.

Why not U?

 As long as it is clear to everyone who uses it....

 <snip>
 RAO       - read, append if exists, fail if not existing.

 That's read, append, overwrite.  Doesn't make sense to me.  Or at 
 least it would be redundant as the end of an initially empty file is 
 the same as the beginning.

 Looks like Derek forgot to prune this one as nonsensical?

 Again, I now suppose it makes sense if the aforementioned semantics of 
 append are implemented.

 WUC       - write, use if exists, create if not existing.
 AUC  "a"  - write(, append if exists), create if not exist.
 WOC  "w"  - write, overwrite existing(, create if not existing).
 RUC       - read, use if exists, create if not existing.

 Not sure about this one.  To create an empty file if the file isn't 
 there, for the benefit of dodgy programs that insist a file exists 
 even if it may be empty?

 Basically it's saying a file should be there (create if not), and I 
 want to read anything that's in it if its there. So you're not having 
 to catch 'file does not exist' exceptions, as in some cases you don't 
 care.

 You mean that if the file isn't there, treat it as empty?  This should 
 be a third option for File-Not-Exists action.  This would stop empty 
 files being created without good cause, and also enable the protocol to 
 be used on write-protected media.

I guess so, I was actually thinking it would create an empty file, but I 
guess treating it as empty without creating it is slightly more useful 
with no drawbacks.

So instead of RUC which would actually create the file you have RUP (p == 
pretend it exists)

 RC        - read, fail if exists, create if not existing. (Used to 
             create an empty file if it doesn't already exist).

 Correction, to require that a file doesn't already exist, but create 
 it as an empty file.  Not sure about this one.

 Simple file locking, i.e. to lock "foobar.dat" we create 
 "foobat.dat.lock" but only if it doesn't already exist (meaning someone 
 has it locked already)

 Which OSs these days don't have their own built-in concept of file 
 locking, which might have the advantage (?) of being automatically 
 released if the locking process dies?

This method has the characteristic of not being automatically released 
when the locking process dies/exits/etc you _might_ be after that 
behaviour.

 <snip>
 True, I think I have demonstrared that by coming up with a few (IMO) 
 sensible uses for ones you did not think were sensible?

 I guess so....

I think, instead of bothering to decide which modes 'make no sense' we 
allow them all and just do what we're told to do, which, may make no sense 
sometimes but that is up to the user of the api to decide.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Stewart Gordon <smjg_1998 yahoo.com> writes:

Regan Heath wrote:

 On Thu, 22 Jul 2004 13:59:59 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
 wrote:

<snip>
 Yes, we could have append as a distinct writing mode, rather than 
 merely a seek.  In that respect, it would be of use even for O and/or 
 C and not U, to force output to be sequential.

 
 Why not U?

By that, I actually meant even if U is not also specified.

<snip>
 You mean that if the file isn't there, treat it as empty?  This should 
 be a third option for File-Not-Exists action.  This would stop empty 
 files being created without good cause, and also enable the protocol 
 to be used on write-protected media.

 
 I guess so, I was actually thinking it would create an empty file, but I 
 guess treating it as empty without creating it is slightly more useful 
 with no drawbacks.
 
 So instead of RUC which would actually create the file you have RUP (p 
 == pretend it exists)

Exactly.

<snip>
 Simple file locking, i.e. to lock "foobar.dat" we create 
 "foobat.dat.lock" but only if it doesn't already exist (meaning 
 someone has it locked already)

 Which OSs these days don't have their own built-in concept of file 
 locking, which might have the advantage (?) of being automatically 
 released if the locking process dies?

 
 This method has the characteristic of not being automatically released 
 when the locking process dies/exits/etc you _might_ be after that 
 behaviour.

<snip>

Yes, you're probably right.  E.g. you want to see the output that was 
generated by the process before it died, before getting back to letting 
other processes mess with it.

Of course, for this whole file locking idea to work, the whole process 
of testing if the file exists and then creating it ought to be atomic, 
just in case.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.

Regan Heath <regan netwin.co.nz> writes:

On Fri, 23 Jul 2004 11:40:43 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
wrote:
 Regan Heath wrote:

 On Thu, 22 Jul 2004 13:59:59 +0100, Stewart Gordon 
 <smjg_1998 yahoo.com> wrote:

 <snip>
 Yes, we could have append as a distinct writing mode, rather than 
 merely a seek.  In that respect, it would be of use even for O and/or 
 C and not U, to force output to be sequential.

 Why not U?

 By that, I actually meant even if U is not also specified.

 <snip>
 You mean that if the file isn't there, treat it as empty?  This should 
 be a third option for File-Not-Exists action.  This would stop empty 
 files being created without good cause, and also enable the protocol 
 to be used on write-protected media.

 I guess so, I was actually thinking it would create an empty file, but 
 I guess treating it as empty without creating it is slightly more 
 useful with no drawbacks.

 So instead of RUC which would actually create the file you have RUP (p 
 == pretend it exists)

 Exactly.

 <snip>
 Simple file locking, i.e. to lock "foobar.dat" we create 
 "foobat.dat.lock" but only if it doesn't already exist (meaning 
 someone has it locked already)

 Which OSs these days don't have their own built-in concept of file 
 locking, which might have the advantage (?) of being automatically 
 released if the locking process dies?

 This method has the characteristic of not being automatically released 
 when the locking process dies/exits/etc you _might_ be after that 
 behaviour.

 <snip>

 Yes, you're probably right.  E.g. you want to see the output that was 
 generated by the process before it died, before getting back to letting 
 other processes mess with it.

 Of course, for this whole file locking idea to work, the whole process 
 of testing if the file exists and then creating it ought to be atomic, 
 just in case.

Correct.. if it's not atomic you have to write something to the file, 
close it, re-open and read to double check it was you that locked it.

The windows CreateFile function has a flag "CREATE_NEW" which "Creates a 
new file. The function fails if the specified file already exists." I 
wonder if it's guaranteed to be atomic or not.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Stewart Gordon <smjg_1998 yahoo.com> writes:

Regan Heath wrote:

<snip>
 Of course, for this whole file locking idea to work, the whole process 
 of testing if the file exists and then creating it ought to be atomic, 
 just in case.

 
 Correct.. if it's not atomic you have to write something to the file, 
 close it, re-open and read to double check it was you that locked it.

<snip>

Let's just hope that the two processes are sufficiently matched in speed 
(which may depend on various factors) that you're not going to get a 
sequence like:

1. Process A checks if file exists - and it doesn't
2. Process B checks if file exists - and it doesn't
3. Process A opens new file
4. Process A writes ID to file
5. Process A closes file
6. Process A reopens file
7. Process A reads back ID - they match - operation succeeded
8. Process B opens new file
9. Process B writes ID to file
10. Process B closes file
11. Process B reopens file
12. Process B reads back ID - they match - operation succeeded

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.

Regan Heath <regan netwin.co.nz> writes:

On Mon, 26 Jul 2004 11:16:49 +0100, Stewart Gordon <smjg_1998 yahoo.com> 
wrote:
 Regan Heath wrote:

 <snip>
 Of course, for this whole file locking idea to work, the whole process 
 of testing if the file exists and then creating it ought to be atomic, 
 just in case.

 Correct.. if it's not atomic you have to write something to the file, 
 close it, re-open and read to double check it was you that locked it.

 <snip>

 Let's just hope that the two processes are sufficiently matched in speed 
 (which may depend on various factors) that you're not going to get a 
 sequence like:

 1. Process A checks if file exists - and it doesn't
 2. Process B checks if file exists - and it doesn't
 3. Process A opens new file
 4. Process A writes ID to file
 5. Process A closes file
 6. Process A reopens file
 7. Process A reads back ID - they match - operation succeeded
 8. Process B opens new file
 9. Process B writes ID to file
 10. Process B closes file
 11. Process B reopens file
 12. Process B reads back ID - they match - operation succeeded

It's a mine field all right I believe you have to use a well placed sleep 
to avoid the above.
Eg.

-check if file exists
-open new file
-write id
-close file
-sleep
-re-open file
-read id

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Derek <derek psyc.ward> writes:

On Thu, 22 Jul 2004 11:56:34 +0100, Stewart Gordon wrote:

 Derek Parnell wrote:
 <snip excessive quote>
 I've devised six codes that encompass these combinations:
 R : read access from start of file
 W : write access from start of file
 A : write access from end of file
 U : use existing file
 O : overwrite existing file
 C : create non-existing file
 
 So the useful combinations that either open a file or fail are (I've also
 show Regan's equivalent codes) ...
 
 RWUC      - read, write, use existing, create if not existing.
 RAUC "a+" - read, append (to existing), create if not exist.

 
 By your system, RA together means that reads start from the beginning, 
 and writes from the end.  Which would mean separate read and write 
 pointers, and extra functions needed to manipulate them.

Yes. So...? Though I'm not sure about needing two cursors. One could have
it so that the first I/O action, if a read moved to the front, and if it
was a write, move to the end. Or maybe even make sure that every write was
at the end of the file.

  RWOC "w+" - read, write, overwrite existing(, create if not existing).
 RWU  "r+" - read, write, fails if file does not exist.
 RAU       - read, append to existing, fail if not exist.
 RWC       - read, write, fail if exists, create if not existing.
 RWO       - read, write, overwrite if exists, fail if not existing.
 RAO       - read, append if exists, fail if not existing.

 
 That's read, append, overwrite.  Doesn't make sense to me.  Or at least 
 it would be redundant as the end of an initially empty file is the same 
 as the beginning.

Yep. This one that should have been culled. I removed all the other AO
combinations but this slipped through.

 WUC       - write, use if exists, create if not existing.
 AUC  "a"  - write(, append if exists), create if not exist.
 WOC  "w"  - write, overwrite existing(, create if not existing).
 RUC       - read, use if exists, create if not existing.

 
 Not sure about this one.  To create an empty file if the file isn't 
 there, for the benefit of dodgy programs that insist a file exists even 
 if it may be empty?

Well it saves the coder having to check the file's existence before
deciding to read it or not. Not sure what's dodgy about that. Oh well, each
to their own.

 ROC       - read, overwrite if exists, create if not existing. (Used to
                  always create an empty file).
 RU   "r"  - read, fails if file does not exist.
 RC        - read, fail if exists, create if not existing. (Used to create
                  an empty file if it doesn't already exist).

 
 Correction, to require that a file doesn't already exist, but create it 
 as an empty file.  Not sure about this one.

I have used this technique to create 'lock' files. If the file already
exists then some other process created it but if not then my process
creates it and others have to wait till I delete it.
 
 RO        - read, overwrite if exists, fail if not existing. (Used to wipe
                  an existing file).
 WU        - write, use if file exists, fail if not existing.
 AU        - write, append if file exists, fail if not existing.
 WC    ""  - write, fail if file exists(, create if not existing).
 WO        - write, overwrite if exists, fail if not existing.(Used to
                  replace an existing file).

 <snip>
 
 Before I looked through your list, I did my own analysis of your 
 enumeration of aspects, which seems the most logical system so far.  I 
 separated W and A, so that R simply means read, W simply means write and 
 A simply means start at the end.  I came up with 16 combinations as 
 making sense:
 
 WUC RWUC WAUC RWAUC WOC RWOC RC RWC RU WU RWU RAU WAU RWAU WO RWO
 
 As you see, I hadn't thought of modes purely to create empty files.  RA, 
 WO and RWO make sense but are of questionable value.  To read starting 
 from the end does make a bit of sense, if you want to look at the end of 
 a file.  But you'd need to seek anyway before you can do anything, so 
 there's little point using it.  And you can recreate a file from 
 scratch, making sure that you're indeed recreating a file that was 
 already there,  but I'm not sure of its practical uses.

Seems that we went through the same thought processes.

 But there's little point in validating the combinations to somebody's 
 conception of making sense, except for the obvious nonsensicality of UO 
 together.

I made this combination mutually exclusive by applying the rule that the
file-exists-action can only have one of three options: Fail, Use,
Overwrite.

-- 
Derek
Melbourne, Australia

"Ben Hinkle" <bhinkle mathworks.com> writes:

To get the behavior Jill describes on Windows, change the two occurrences of
OPEN_ALWAYS in stream.d to
 (mode&FileMode.Out)?OPEN_ALWAYS:OPEN_EXISTING
and recompile phobos. I don't know about Linux.

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cdlm9m$2kle$1 digitaldaemon.com...
 On the Windows platform:








 creates the file "foo", does not throw any kind of exception, and then

carries
 on executing as though everything were hunky dory.

 This is currently a very good reason not to use std.stream.File

 Arcane Jill

Andrew Edwards <ridimz_at yahoo.dot.com> writes:

Arcane Jill wrote:
 On the Windows platform:
 






 
 creates the file "foo", does not throw any kind of exception, and then carries
 on executing as though everything were hunky dory.
 
 This is currently a very good reason not to use std.stream.File
 
 Arcane Jill
 
 

You know! I remember when this feature operated the way you now expect 
it to. Others requested that it be changed and it was. Just goes to 
show: you can't please everyone. No matter how hard you try!

Andrew

Andrew Edwards <ridimz_at yahoo.dot.com> writes:

Andrew Edwards wrote:

 Arcane Jill wrote:
 
 On the Windows platform:








 creates the file "foo", does not throw any kind of exception, and then 
 carries
 on executing as though everything were hunky dory.

 This is currently a very good reason not to use std.stream.File

 Arcane Jill

 You know! I remember when this feature operated the way you now expect 
 it to. Others requested that it be changed and it was. Just goes to 
 show: you can't please everyone. No matter how hard you try!
 
 Andrew

As a matter of fact, here's the post that prompted the change:

   http://www.digitalmars.com/d/archives/17539.html

Andrew Edwards <ridimz_at yahoo.dot.com> writes:

Andrew Edwards wrote:
 
 As a matter of fact, here's the post that prompted the change:
 
   http://www.digitalmars.com/d/archives/17539.html

Teaches me for opening my mouth too fast. He was talking about 
"FileMode.Out".

I'll shut up now!