Undeleting a file overwritten with mv

i guess one can alias for the root user too but its annoying.

Google:

bash set noclobber option

and

bash set command

and see

https://www.gnu.org/software/bash/manual/html_node/The-Set-B...

> That will work if your file isn't fragmented on the disk, I guess.

Even 15 years ago when I was doing digital forensics it was actually pretty uncommon to have to deal with fragmentation. After about 2000 filesystem allocation implementations started avoiding it like the plague.

My guess as to the cause of that corruption is that the file was slightly fragmented, but the fragments were pretty close together, and streaming video formats are resilient enough to tolerate some garbage in the middle of the stream.

IIRC photorec should be able to handle this.

If you want to emulate this by hand, first get the fd number of the file of interest by `ls -l /proc/PID/fd/` and then `cat /proc/PID/fdinfo/NUMBER`. There is a line called "pos", which is the position in the file.

But let’s say they were taking backups. “Always have a backup” turns out not always be enough.

Perhaps the overwritten file was new enough that it hadn’t been backed up yet.

Perhaps they didn’t realize their mistake until after the backup process had run, and the backup no longer contained the file they had overwritten.

Perhaps they attempted to restore the overwritten file from backup and discovered that the backup process had actually been failing but they had insufficient testing or notifications.

Point is, backups have an engineering, hardware, and complexity cost, too. I don’t know enough about their tradeoffs to judge them for making the wrong decision here.

That said, I do agree that in general, the default choice should be automated backups, with multiple sets for different time intervals, in a mixture of on- and off-site storage, with regular automated restoration tests.

Then the OP could have done:

  zfs-restore-file recording-16679.flv

  #!/bin/bash
  
  FILE="$1"
  FULL_PATH=$(realpath "$FILE")
  DATASET=$(findmnt --target="${FULL_PATH}" --output=SOURCE --noheadings)
  MOUNT_POINT=$(findmnt --source="${DATASET}" --output=TARGET --noheadings | head -n1)
  CURRENT_INODE="$(stat -c %i "${FULL_PATH}")"
  RELATIVE_PATH="$(echo "$FULL_PATH" | sed "s|^${MOUNT_POINT}/||")"
  
  # iterate all snapshots of the dataset containing the file, most recent first
  for SNAPSHOT in $( \
    zfs list -t snapshot -H -p -o creation,name "${DATASET}" \
    | sort -rn | awk '{print $2}' | cut -d@ -f2 \
  ) ; do
    echo "snapshot $DATASET @ $SNAPSHOT"
    SNAPSHOT_FILE="${MOUNT_POINT}/.zfs/snapshot/${SNAPSHOT}/${RELATIVE_PATH}"
    SNAPSHOT_FILE_INODE="$(stat -c %i "${SNAPSHOT_FILE}")"
    if [ "${SNAPSHOT_FILE_INODE}" == "" ] || [ "${SNAPSHOT_FILE_INODE}" == "${CURRENT_INODE}" ] ;   then
      continue
    fi
    echo "found the same named file with a different inode:"
    ls -l "${SNAPSHOT_FILE}"
    cp -i "${SNAPSHOT_FILE}" "${FILE}"
    break
  done

If you symlink "./public/recording" to "./recording", the public file only exists as long as the original file exists. Some automated cleanup could result in unexpected file deletions from "public/" (or, more specifically, the creation of dangling symlinks). However, this might be a use case for a hard link if you need the file in both places and both directories are on the same filesystem. Though I haven't thought about the implications of a hard link in this case enough so far.

As a bonus, ln will not overwrite the destination file if you mistakenly try to "ln" it to an existing file.

I think file systems run into technical and psychological issues.

The major obvious technical issue is simply running out of space, and how you deal with that informs many other aspects of such a system. The other issue is how the user figures out what action they need to undo. High level applications have an integrated interface, so the user is directly issuing commands into the application's event loop, and the undo feature is also integrated into that event loop.

But you don't directly make calls to the filesystem; deletions or updates are always issued by a process acting on your behalf. Many processes are generating a ton of temporary data, so while these actions shouldn't be undoable, there's no general way for the filesystem to know this. A user attempting to undo an action would have to sift through a flood of irrelevant history.

The first psychological issue is the user's intent. Software applications tend to make this a two-step process: you make revocable changes, then when you hit "save" your actions become irrevocable. You move a file to the trash, and you can take it up, but when you empty trash it's irrevocable.

For a filesystem, again, because applications are acting on their behalf, this connection is largely lost. There's no clear "save point" where changes should be lost, so maybe you could add a "force" flag to make changes permanent. But if you start adding a "force" flag to actions, you'll change user behavior; if they have to force actions to make them permanent, they may start to do that routinely.

And there's a moral hazard produced by insuring that actions are revocable; if users get used to having an "undo," they will naturally begin to rely on it. If the system has to automatically make changes irrevocable (running low on disk space), then you'll get situations where users are screwed because they assumed they'd have undo to fall back on.

And, of course, users can be screwed when they thought they had deleted (or changed) something and it wasn't. This is already something forensics experts can do, but a generic undo feature lowers that bar to the nosey middle manager.

>be ause then only the printable ASCII characters woyls

should be

because then only the printable ASCII characters would