Talk:Append a record to the end of a text file: Difference between revisions

From Rosetta Code
Content added Content deleted
m (→‎CSV?: Agreed.)
Line 5: Line 5:
: Still needs some work IMO; it's got lots of small bits and pieces jumbled together without quite a coherent story. It's probably not that hard to improve it to the point of being good though.
: Still needs some work IMO; it's got lots of small bits and pieces jumbled together without quite a coherent story. It's probably not that hard to improve it to the point of being good though.
: And as a side note, POSIX systems have the O_APPEND flag to the open() syscall which makes this trivial (if it is exposed by the language) provided appropriate flushing is used. (Even better, the flag is inheritable by subprocesses; that's a ''very'' useful thing at times.) By contrast, on Windows you need to lock the file to do this safely and that's error prone and much more complex in practice. Moreover, locks aren't inheritable (of course). Damn, but I wish the folks at Redmond actually ''understood all'' of POSIX properly, as it has some really wonderful things in there. –[[User:Dkf|Donal Fellows]] 13:58, 12 September 2011 (UTC)
: And as a side note, POSIX systems have the O_APPEND flag to the open() syscall which makes this trivial (if it is exposed by the language) provided appropriate flushing is used. (Even better, the flag is inheritable by subprocesses; that's a ''very'' useful thing at times.) By contrast, on Windows you need to lock the file to do this safely and that's error prone and much more complex in practice. Moreover, locks aren't inheritable (of course). Damn, but I wish the folks at Redmond actually ''understood all'' of POSIX properly, as it has some really wonderful things in there. –[[User:Dkf|Donal Fellows]] 13:58, 12 September 2011 (UTC)
:: I am not sure I agree. As I understand it, under unix, locking is advisory -- you cannot enforce it on other programs, and only if every program accessing the file uses the same mechanism do locked files get protected (fcntl is one example but other mechanisms do get used, especially if people are attempting to support nfs). That said, if processes are designed so that collisions are rare, locking might not be necessary. Also, often unix's atomic file rename mechanism is used to avoid locking issues. Meanwhile, under windows, the default behavior is that only one program can have the file open for writing -- by default, you get an error when another program tries to open the file for writing. The windows behavior can be painful, and there's no atomic file rename, but any locking mechanism that gets enforced by the OS can be painful to work with. Meanwhile, all of these characteristics are properties of the operating system and not of the language. --[[User:Rdm|Rdm]] 02:16, 13 September 2011 (UTC)


== CSV? ==
== CSV? ==

Revision as of 02:16, 13 September 2011

Rationale

Basically I was looking for an example of appending an actual record to a file and found no such task.

(This was written by NevilleDNZ (Talk | contribs) at 10:59, 12 September 2011)
Still needs some work IMO; it's got lots of small bits and pieces jumbled together without quite a coherent story. It's probably not that hard to improve it to the point of being good though.
And as a side note, POSIX systems have the O_APPEND flag to the open() syscall which makes this trivial (if it is exposed by the language) provided appropriate flushing is used. (Even better, the flag is inheritable by subprocesses; that's a very useful thing at times.) By contrast, on Windows you need to lock the file to do this safely and that's error prone and much more complex in practice. Moreover, locks aren't inheritable (of course). Damn, but I wish the folks at Redmond actually understood all of POSIX properly, as it has some really wonderful things in there. –Donal Fellows 13:58, 12 September 2011 (UTC)
I am not sure I agree. As I understand it, under unix, locking is advisory -- you cannot enforce it on other programs, and only if every program accessing the file uses the same mechanism do locked files get protected (fcntl is one example but other mechanisms do get used, especially if people are attempting to support nfs). That said, if processes are designed so that collisions are rare, locking might not be necessary. Also, often unix's atomic file rename mechanism is used to avoid locking issues. Meanwhile, under windows, the default behavior is that only one program can have the file open for writing -- by default, you get an error when another program tries to open the file for writing. The windows behavior can be painful, and there's no atomic file rename, but any locking mechanism that gets enforced by the OS can be painful to work with. Meanwhile, all of these characteristics are properties of the operating system and not of the language. --Rdm 02:16, 13 September 2011 (UTC)

CSV?

Is it supposed to be a CSV file? The description doesn't say anything about the file format, unless "passwd" implies some sort of format. Maybe the given records should be specified in the description. --Mwn3d 23:57, 12 September 2011 (UTC)

Agreed. Will do.

The essence of the task is "Append a record to the end of a text file". Crudely speaking:

  • A record is something that has multi fields.
  • A text file is something that can be edited with "notepad"
    • in essence it does not contain "raw binary integers" etc.
    • The text file "record" represents the original record fields.

I want to avoid simply appending random text to the end of an arbitrary file as nominally programs are (concurrently) manipulating (and storing) structures of data.

NevilleDNZ 01:44, 13 September 2011 (UTC)