The normally correct use of os.WriteFile doesn't work in a docker container because '/etc/resolv.conf is special and magical in docker, and os.WriteFile seems to implicitly try to unlink the file to truncate it which isn't entirely clear based on the documentation (I guess it's an implementation detail that isn't guaranteed?).
This changes that behavior to first trying to use os.WriteFile, and if that fails it also tries an alternate method to seek to the beginning of the file and write from there, which shouldn't attempt to truncate/create a new file.
My understanding of the go ecosystem is very limited, so there may be another way to go about this.
This also avoids the code path that attempts to restore the backup with os.WriteFile. What I've observed is that the /etc/resolv.conf is restored in any case, I'm not clear on the mechanism that does this, but I can verify that the file is updated while the hide.me service is running.
The normally correct use of
os.WriteFile
doesn't work in a docker container because'/etc/resolv.conf
is special and magical in docker, andos.WriteFile
seems to implicitly try to unlink the file to truncate it which isn't entirely clear based on the documentation (I guess it's an implementation detail that isn't guaranteed?).This changes that behavior to first trying to use
os.WriteFile
, and if that fails it also tries an alternate method to seek to the beginning of the file and write from there, which shouldn't attempt to truncate/create a new file.My understanding of the go ecosystem is very limited, so there may be another way to go about this.
This also avoids the code path that attempts to restore the backup with
os.WriteFile
. What I've observed is that the/etc/resolv.conf
is restored in any case, I'm not clear on the mechanism that does this, but I can verify that the file is updated while the hide.me service is running.