SpaceCadet

joined 1 year ago
[–] SpaceCadet@feddit.nl 5 points 2 months ago (5 children)

yet all I needed is a "this side up" symbol ...

[–] SpaceCadet@feddit.nl 5 points 2 months ago (3 children)

Since you forgot to add - - preserve-root It won’t go too far

Go on then ... try it.

Or don't because you will erase your system. (Hint: it's in the asterisk)

[–] SpaceCadet@feddit.nl 2 points 2 months ago

as the binary is already loaded into memory

That’s not the reason why it continues. It’s because there’s still a file descriptor open to rm.

[–] SpaceCadet@feddit.nl 2 points 2 months ago* (last edited 2 months ago)

That’s not the reason why it continues. It’s because there’s still a file descriptor open to rm.

[–] SpaceCadet@feddit.nl 18 points 2 months ago* (last edited 2 months ago)

In Unix/Linux, a removed file only disappears when the last file descriptor to it is gone. As long as the file /usr/bin/rm is still opened by a process (and it is, because it is running) it will not actually be deleted from disk from the perspective of that process.

This also why removing a log file that's actively being written to doesn't clear up filesystem space, and why it's more effective to truncate it instead. ( e.g. Run > /var/log/myhugeactivelogfile.log instead of rm /var/log/myhugeactivelogfile.log), or why Linux can upgrade a package that's currently running and the running process will just keep chugging along as the old version, until restarted.

Sometimes you can even use this to recover an accidentally deleted file, if it's still held open in a process. You can go to /proc/$PID/fd, where $PID is the process ID of the process holding the file open, and find all the file descriptors it has in use, and then copy the lost content from there.

[–] SpaceCadet@feddit.nl 2 points 2 months ago* (last edited 2 months ago) (1 children)
[–] SpaceCadet@feddit.nl 2 points 2 months ago* (last edited 2 months ago)

Leave the poor kernel out of it, it has nothing to do with this. It's Lennart, not Linus.

[–] SpaceCadet@feddit.nl 3 points 2 months ago (1 children)

I don't think it's intended as a "solution", it just lets the clobbering that is caused by the case insensitiveness happen.

So git just goes:

  • checkout content of README.md to README.md (OS creates README.md)
  • checkout content of README.MD to README.MD (OS overwrites README.md)

If you add a third or fourth file ... it would just continue, and file gets checked out first gets the filename and whichever file gets checked out last, gets the content.

[–] SpaceCadet@feddit.nl 2 points 2 months ago

Depending upon their genre and your city’s size, they may never come nearby you

The joy of living in a central, densely populated area of Europe ... I've been able to see almost all niche bands that I'm into live.

[–] SpaceCadet@feddit.nl 1 points 2 months ago (1 children)

The problem with that is that they are usually in tiny venues, often with no seating (some of us have issues with standing for a few hours straight), and absolutely terrible acoustics.

Not true at all where I live, except for the seating part sometimes. There are many small to midsized venues with ticket prices well below €50, and they all have way better accoustics than the large concert halls, and it's a much more personal experience than in a >10,000 people venue because you can be way up close with the artists.

For example, these are all venues I've visited in recent years, I rarely paid more than €30 for a ticket:

[–] SpaceCadet@feddit.nl 4 points 2 months ago (3 children)

It tells you there's a name clash, and then it clones it anyway and you end up with the contents of README.MD in README.md as an unstaged change.

view more: ‹ prev next ›