On Tue, Oct 25, 2011 at 12:52 AM, Christian Engelmayer
<[email protected]> wrote:
> Function log_locally() within the syslogd can potentially lock up when
> restarting the daemon after a power loss in case the unplanned shutdown hit
> the
> rename operation during logfile rotation.
>
> While POSIX requires the rename operation to be atomic, many file systems such
> as JFFS2 implement the rename operation in 2 steps by linking the new name
> followed by unlinking the original name. In case of a power loss during the
> rename the system can end up with /var/log/messages and /var/log/messages.0
> being 2 hard links to the same file.
>
> When the syslog daemon restarts in such a situation it will rediscover the
> need
> to rotate the log files, however, POSIX also requires that rename does nothing
> and reports success in case oldpath and newpath are existing hard links to the
> same file.
Which is a totally bogus requirement, I would say.
rename("A", "B") should succeed if A and B are hardlinks (ok),
but A should still exist after (what!!?!?!!!!!????).
It's incredible they had audacity to put such nonsense into standard.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
The page says in "RATIONALE" section:
'The specification that if old and new refer to the same file is
intended to guarantee that:
rename("x", "x");
does not remove the file.'
Why didn't they just explicitly say in normative section that what they actually
want is for THIS particular case to work correctly, not OTHER cases to
be fucked up?!
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
