I see the same behavior on Linux, Solaris 2.5, and our own SVR4-based UTS.
I establish file foo with an echo or two. Then I run "tail -f foo >
redirect" to it
and (in a separate xterm) ls -l to check the sizes of the files. Both
are the same. Then I run
cat /dev/null > redirect and again I run ls -l; the redirect file is now
at zero bytes.
Then I run echo abc >> foo and run ls -l again; sure enough, the size of
the redirect file
is the same as the size of foo, where you would expect a count of 4
bytes. My redirect file now
starts (in all three platforms) with bytes containing 0x00.
I conclude that Linux works like it's supposed to work.
Richard Hitt [EMAIL PROTECTED]
Fuzzy Logic wrote:
If I had to guess, I would suspect that the application in question is
doing an fseek before every fwrite, and thus, this will happen for
both ext2 and ext3, and probably for a number of other filesystems,
but I've not tried this test on them.
Fuzzy
On 3/7/06, Brandon S. Darbro <[EMAIL PROTECTED]> wrote:
I know when it will happen, my question is why? I don't have this
problem on Solaris and HP. Is it a "feature" of the ext2 / ext3
filesystem? Or is will Linux do this on any of it's fs types?
logrotate may be a useful solution for regular daemon log files, but
it's also a problem with a users personal xsession log files as well.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
