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

m (→‎CSV?: Agreed.)
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.
: 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? ==
6,962

edits