Johannes Meixner

@pcahyna perhaps some time-limited cache or something else. What matters is that one cannot rely on NFS to behave predictably from a user's point of view. Of course from the...

Finally I found time to have a look at https://github.com/gdha/lnxutils/blob/master/opt/ncsbin/lnxutils/nfs_stale_handle_check.sh As far as I see its basic idea is to run a command that may not return with ``` timeout...

The more I am thinking about it in general the more I come to the conclusion that in general (i.e. except exceptions) ReaR should not deal with broken things or...

@rear/contributors if one of you knows a reasonably simple and generic way that works reliable over time how to deal with unresponsive NFS mounts please contribute it via a pull...

@pcahyna could you please have a look here (as time permits), cf. https://github.com/rear/rear/pull/3171#issuecomment-1972887597

Some further thoughts regarding the get_var_from_file() function: Because at least at first glance it looks rather confusing what $0 $1 $2 actually is when looking at the get_var_from_file() function code,...

@lzaoral I am afraid - again it gets long and longer. Hopefully you don't mind too much when I make such kind of pedantic comments?

I like `bash -euc` very much because it is simple and it makes useful use of the "bash in between" which was up to now more a workaround for `source`...

Regarding https://github.com/rear/rear/pull/3171#issuecomment-2015507343 I do fully agree. Meanwhile (after I had some "deep thought" about it over the weekend) I consider hardcoded "transitive DEBUG options setting" a horrible idea regarding security...

The current implementation ``` # function get_var_from_file() { bash -c 'source "$0"; echo "${!1}"' "$1" "$2" ; } ``` does not yet work correctly when there is stdout output of...