[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22768: Crash safety

From: Antonio Diaz Diaz
Subject: bug#22768: Crash safety
Date: Sat, 27 Feb 2016 01:17:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv: Gecko/20070601 SeaMonkey/1.1.2

Paul Eggert wrote:
Why -y? And why a short name at all? I don't expect this to be something that people will want to type by hand.

Because ddrescue already provides the option '-y, --synchronous' for a somewhat similar functionality. (It is in my first message). I find short option names handy, but I have no problem implementing this as long-only.

Come to think of it, gzip should also do an fsync, or at least an fdatasync, on the destination's directory before removing the source.

Doing it right in all circumstances may be impossible. Also fsync may be a no-op in some systems and very expensive in others. And some systems are safe without the need of fsync. This is why my first idea was to leave the safety to the system by default and add an option to enable the "maybe safer but slower" behavior.

And this suggests that any long option name shouldn't be something syscall-specific like '--no-fsync', but should instead be something more general and easy to remember, e.g., '--hasty'.

I had to search 'hasty' in the dictionary, so I think it is perhaps not so good and easy to remember for non-English speakers. OTOH, many people using a CLI know what 'fsync' or 'sync' mean.

Just now my preference is to make the behavior optional and call the option --fsync. I think both points meet the principle of least surprise.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]