##// END OF EJS Templates
posix: always seek to EOF when opening a file in append mode...
posix: always seek to EOF when opening a file in append mode Python 3 already does this, so skip it there. Consider the program: #include <stdio.h> int main() { FILE *f = fopen("narf", "w"); fprintf(f, "narf\n"); fclose(f); f = fopen("narf", "a"); printf("%ld\n", ftell(f)); fprintf(f, "troz\n"); printf("%ld\n", ftell(f)); return 0; } on macOS, FreeBSD, and Linux with glibc, this program prints 5 10 but on musl libc (Alpine Linux and probably others) this prints 0 10 By my reading of https://pubs.opengroup.org/onlinepubs/009695399/functions/fopen.html this is technically correct, specifically: > Opening a file with append mode (a as the first character in the > mode argument) shall cause all subsequent writes to the file to be > forced to the then current end-of-file, regardless of intervening > calls to fseek(). in other words, the file position doesn't really matter in append-mode files, and we can't depend on it being at all meaningful unless we perform a seek() before tell() after open(..., 'a'). Experimentally after a .write() we can do a .tell() and it'll always be reasonable, but I'm unclear from reading the specification if that's a smart thing to rely on. This matches what we do on Windows and what Python 3 does for free, so let's just be consistent. Thanks to Yuya for the idea.

File last commit:

r40070:393e4432 default
r43163:97ada9b8 5.0.2 stable
Show More
test-wireproto-command-known.t
58 lines | 1.3 KiB | text/troff | Tads3Lexer
/ tests / test-wireproto-command-known.t
$ . $TESTDIR/wireprotohelpers.sh
$ hg init server
$ enablehttpv2 server
$ cd server
$ hg debugdrawdag << EOF
> C D
> |/
> B
> |
> A
> EOF
$ hg log -T '{rev}:{node} {desc}\n'
3:be0ef73c17ade3fc89dc41701eb9fc3a91b58282 D
2:26805aba1e600a82e93661149f2313866a221a7b C
1:112478962961147124edd43549aedd1a335e44bf B
0:426bada5c67598ca65036d57d9e4b64b0c1ce7a0 A
$ hg serve -p $HGPORT -d --pid-file hg.pid -E error.log
$ cat hg.pid > $DAEMON_PIDS
No arguments returns something reasonable
$ sendhttpv2peer << EOF
> command known
> EOF
creating http peer for wire protocol version 2
sending known command
response: []
Single known node works
$ sendhttpv2peer << EOF
> command known
> nodes eval:[b'\x42\x6b\xad\xa5\xc6\x75\x98\xca\x65\x03\x6d\x57\xd9\xe4\xb6\x4b\x0c\x1c\xe7\xa0']
> EOF
creating http peer for wire protocol version 2
sending known command
response: [
True
]
Multiple nodes works
$ sendhttpv2peer << EOF
> command known
> nodes eval:[b'\x42\x6b\xad\xa5\xc6\x75\x98\xca\x65\x03\x6d\x57\xd9\xe4\xb6\x4b\x0c\x1c\xe7\xa0', b'00000000000000000000', b'\x11\x24\x78\x96\x29\x61\x14\x71\x24\xed\xd4\x35\x49\xae\xdd\x1a\x33\x5e\x44\xbf']
> EOF
creating http peer for wire protocol version 2
sending known command
response: [
True,
False,
True
]
$ cat error.log