Japan HP accidentally deleted 77TB data in Kyoto U. supercomputing system

    /bin/sh -eu

That is dependent on the OS. In this case wasn't the shell script just executed fresh from a cronjob?

I remember on Digital Unix - on an Alpha so this was a few years ago - that you could change a c program (a loop that printed something then slept, for example), recompile and it would change the running binary.

As I understand it, the reason for ETXTBSY ("on some old Unices...you can't overwrite a running binary") was to prevent segfaults.

cp usually just opens the file O_WRONLY|O_TRUNC, which seems like the wrong default; Emacs for example does create a new file and rename it over the old one when you save, usually, allocating a new inode as you say. By default it makes an exception if there are other hardlinks to the file.

Btrfs and xfs have a "reflink" feature that allows you to efficiently make a copy-on-write snapshot of a file, which would be ideal for this sort of thing, since the shell or whatever won't see any changes to the original file, even if it's overwritten in place. Unfortunately I don't think you can make anonymous reflinks, so for the shell to reflink a shell script when it starts executing it would need write access to somewhere in the filesystem to put the reflink, and then it would need to know how to find that place, somehow. And of course that wouldn't help if you were running on ext4fs or, I imagine, Lustre, though apparently an implementation was proposed in 02019: https://wiki.lustre.org/Lreflink_High_Level_Design

That's the route chosen by Windows for binary executables (exe/dll) and various other systems. Locking a file against writes, delete/rename or even read is just another flag in the windows equivalent of fopen [1]. This makes for software that's quite easy to reason about, but hard to update. The reason why you have to restart Windows to install Windows updates or even install some software is largely due to this locking mechanism: you can't update files that are open (and rename tricks don't work because locks apply to files, not inodes).

With about three decades of hindsight I'm not sure if it's a good tradeoff. It makes it easy to prevent the race conditions that are an endless source of security bugs on unix-like systems; but otoh most software doesn't use the mechanism because it's not in the lowest-common-denominator File APIs of most programming languages; and MS is paying for it with users refusing to install updates because they don't want to restart their PC.

1: Search for FILE_SHARE_DELETE in https://docs.microsoft.com/en-us/windows/win32/api/fileapi/n...

this is incorrect, and is relatively easy to test:

  $ strace -y -P /tmp/test.sh bash /tmp/test.sh
  ioctl(3</tmp/test.sh>, TCGETS, 0x7ffc6daea580) = -1 ENOTTY (Inappropriate ioctl for device)
  lseek(3</tmp/test.sh>, 0, SEEK_CUR)     = 0
  read(3</tmp/test.sh>, "#!/bin/sh\n", 80) = 10
  lseek(3</tmp/test.sh>, 0, SEEK_SET)     = 0
  dup2(3</tmp/test.sh>, 255)              = 255</tmp/test.sh>
  close(3</tmp/test.sh>)                  = 0
  fcntl(255</tmp/test.sh>, F_SETFD, FD_CLOEXEC) = 0
  fcntl(255</tmp/test.sh>, F_GETFL)       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
  newfstatat(255</tmp/test.sh>, "", {st_mode=S_IFREG|0644, st_size=10, ...}, AT_EMPTY_PATH) = 0
  lseek(255</tmp/test.sh>, 0, SEEK_CUR)   = 0
  read(255</tmp/test.sh>, "#!/bin/sh\n", 10) = 10
  read(255</tmp/test.sh>, "", 10)         = 0

  #!/bin/sh
  main() {
  # script goes here
  }
  main

By reading in the whole file at once. Bash does not mmap shared the script it is parsing. You can see this behavior with

    strace -e read,lseek bash << EOF
    echo 1
    echo 2
    EOF

The other way to fix this is to simply use editors that will just make a new file and move over that file on the target on save. I believe vim or neovim does this by default, but things like, ed or vi do not. Emacs will do something similar on first save if you did not (setq backup-by-copying t) but any write after will still be done in-place. I tested this trivially without reviewing the emacs source simply doing the following and you can to with $EDITOR of choice:

    !#/usr/bin/env bash
    echo test
    sleep 10
    # evil command below, uncomment me and save
    # echo test2

Options, as in I also found out about them the hard way.

HP does consumer grade stuff only, while HPE does the enterprise side (not just consulting, in fact non trivial portion of HPE consulting arm was spun off and merged into DXC)

Voluntarily stating 100% responsibility is consequential and not typical, smells politics.

I'm not a Japanophile, but find their culture fascinating.

[1]: https://theculturetrip.com/asia/japan/articles/sumimasen-beh...

> * 真 makoto, a word often glossed as "sincere" but not identical in meaning: it's about the amount of effort you're willing to take on, not how "honestly" you feel something

While it's true that makoto can be translated as sincere(ly) in constructions like "makotoni moushiwakearimasen" (I sincerely apologize) (although this is written 誠に rather than 真に), it is unlikely that the word makoto would be used in a phrase like "a sincere apology" or in discussing how sincere an apology was, so I don't really think introducing the word "makoto" in your comment sheds any additional light on japanese culture surrounding apologies.

You could actually make the exact same comment about how "real" in English can also effectively mean sincere in "really sorry" and draw the same conclusions about American culture.

source? this is a popular theory among non-lawyers, but not, as far as I can tell, well-supported by the evidence. http://jaapl.org/content/early/2021/05/19/JAAPL.200107-20 has extensive citations including for their claim that "In theory, telling a patient about an error may make patients more likely to pursue litigation. In practice, however, bad outcomes alone are typically not reason enough for patients or their families to file malpractice claims."

——-

“hospital staff and doctors willing to discuss, apologize for and resolve adverse medical events through a “collaborative communication resolution program” experienced a significant decrease in the filing of legal claims, defense costs, liability costs and time required to close cases.”

https://www.natlawreview.com/article/you-had-me-i-m-sorry-im...