: / exists in filesystem (owned by )

pn · 2023-08-29 13:23:23

Why not managing that problem like that

```
#!/bin/bash

# Run the system update and capture the failed output
update_output=$(sudo pacman -Syu 2>&1)

# Extract the list of files that caused conflicts from the output
conflicting_files=($(echo "$update_output" | grep -oE '/[^ ]+' | sort -u | tail +2))

# Backup the conflicting files with .pacold extension
for file in "${conflicting_files[@]}"; do
# Check if the file exists before renaming
if [[ -f "$file" ]]; then
backup_name="${file}.pacold"
# Rename while avoiding overwriting existing backup files
if [[ -f "$backup_name" ]]; then
counter=1
while [[ -f "${backup_name}.${counter}" ]]; do
((counter++))
done
backup_name="${file}.pacold.${counter}"
fi
sudo mv "$file" "$backup_name"
fi
done

# Retry the system update
sudo pacman -Syu
```

Instead of `--overwrite '*'`? Because if overwriting was the solution, then it would be automatic, without any flag to specify. If it is to specify it's that it's not the systematic solution. So if overwriting is not always good, isn't backuping always good? At least making it an option if even backup can be problematic for people really wanting to not touch anything

Scimmia · 2023-08-29 13:31:19

Because if there's a conflict, you need to stop and figure out why, not just blindly rename or overwrite.

pn · 2023-08-29 13:36:11

Okay, so what about making an option? If overwrite is one, backup should too

Scimmia · 2023-08-29 13:37:45

If you've checked things out, you could have already made the backups where needed.

pn · 2023-08-29 13:48:02

It can be a safe solution, overwrite making automatically a backup so if there is a problem, there is a backup

Scimmia · 2023-08-29 13:50:42

Then restoring the backup also causes problems. Now what?

Again, figure out WHY there's a conflict before anything, then you know what you need to do. If you end up with 2 packages owning the same file, no backup is going to save you.

pn · 2023-08-29 13:52:15

Nobody talked about restoring backups, it is only about creating them, to the user don't lose them

Often there is two package owners that selected the same file, but it's not the problem here to resolve PKGBUILDs, it's only about not losing files

seth · 2023-08-29 14:33:25

Often there is two package owners that selected the same file

Name two examples.

You're not supposed to run in such conflicts.
If you do, --overwrite can be one possible mitigation, but you need to understand the cause of the conflict and fix that.
Silently and automatically glossing over this by spamming the system w/ most likely pointless "backups" is akin to this approach:

pn · 2023-08-29 15:23:51

It's not about "glossing over". It's about when you make the overwrite choice to make a backup automatically, just in case

seth · 2023-08-29 15:36:51

Your script looksfor collisions, UNCONDITIONALLY moves them away and runs an update - how is that not "glossing over"?

Also, just in case of *what*?
By the time you issue an --overwrite you're supposed to have understood the collision and inferred that the existing file can be discarded. At that point "backups" aren't required.

You're looking for a way to non-interactively get collisions out of the way, but you are not supposed to encounter such collisions and user interaction is absolutely required in this situation.

Arch Linux

#1 2023-08-29 13:23:23

: / exists in filesystem (owned by )

#2 2023-08-29 13:31:19

Re: : / exists in filesystem (owned by )

#3 2023-08-29 13:36:11

Re: : / exists in filesystem (owned by )

#4 2023-08-29 13:37:45

Re: : / exists in filesystem (owned by )

#5 2023-08-29 13:48:02

Re: : / exists in filesystem (owned by )

#6 2023-08-29 13:50:42

Re: : / exists in filesystem (owned by )

#7 2023-08-29 13:52:15

Re: : / exists in filesystem (owned by )

#8 2023-08-29 14:33:25

Re: : / exists in filesystem (owned by )

#9 2023-08-29 15:23:51

Re: : / exists in filesystem (owned by )

#10 2023-08-29 15:36:51

Re: : / exists in filesystem (owned by )

Board footer