Filesystem writes seemingly lost

Question

I've been experimenting with tcpdump, and I've found some very bizarre filesystem behavior. It doesn't look to be a tcpdump problem as I'll explain in a second.

The following command produces no file:

tcpdump -w test.pcap

Yet this command produces the PCAP file as expected:

tcpdump -w - > test.pcap

At first I figured that tcpdump must be encountering some error when writing the file that the shell wasn't, so I straced and found that the writes were occurring just fine!

open("test.pcap", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff9bf5cb000
rt_sigaction(SIGUSR1, {0x4557d0, [], SA_RESTORER, 0x7ff9bea2ab60}, {SIG_DFL, [], 0}, 8) = 0 
write(2, "tcpdump: ", 9tcpdump: )                = 9 
write(2, "listening on eth0, link-type EN1"..., 73listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes) = 73
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "\324\303\262\241\2\0\4\0\0\0\0\0\0\0\0\0\377\377\0\0\1\0\0\0001\2\210P\34\3\3\0"..., 4096) = 4096
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "\232\241\4\17X\213\f9+\225\35\t\364QF\223\242\7\217Y\226\373l\231vQ\354\223\250i\336."..., 4096) = 4096
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(4, "\34\226\346%\354\210\342\331\377\373\222d\261\0\5\207wX\6i`\0U\260\350\260\300\250\0\16\335\241"..., 4096) = 4096

test.pcap gets opened as file descriptor 4, and then several writes occur to that descriptor with the syscall reporting that the requested number of bytes was in fact written.

Even so, no file is created. I scoured the filesystem for test.pcap and found nothing.

What could produce this behavior?

tcpdump version 4.3.0
libpcap version 1.3.0
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Linux persephone 3.4.9-gentoo #1 SMP Wed Oct 3 10:02:39 EDT 2012 x86_64 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz GenuineIntel GNU/Linux

Answer 1

tcpdump is doing something else to the file. You don't say what the full command-line is; perhaps you have a -G in there.

Possible ways to investigate further:-

1. Keep looking through the strace output: maybe you'll find a rename or unlink.
2. While tcpdump is running, run ln test.pcap pin.test.pcap and you'll be able to tell if the file was unlinked later.
3. While tcpdump is running, find its process ID and ls -l /proc/${pid}/fd to see if you can spot the link to the open file's full pathname. (This is the approach that actually worked, from @Gilles' comment.)