As the links pointed out you can no longer relink but you can certainly access the data. So the append it working - you just can’t see it using ls. Anyway, I guess you have enough knowledge now to address. On Dec 10, 2023, at 1:34 PM, Jason E. Aten wrote:Thanks Robert.On Sunday, December 10, 2023
On Sun, Dec 10, 2023 at 8:34 PM Jason E. Aten wrote:
> I noticed that the binary log was not growing, and its update timestamp was
> not changing.
I think the file was still growing as intended. It was only no more
associated with the _new_ entry/name in the directory. I'm pointing it
out becau
Thanks Robert.
On Sunday, December 10, 2023 at 6:30:11 PM UTC Robert Engels wrote:
Not sure how you are detecting that the append it not working -
I noticed that the binary log was not growing, and its update timestamp was
not changing. I have an alias, lh, that is
alias lh='ls -alFtrh|tail'
You basically already showed how to do it on Linux: inside your Go prog,
you know the file descriptor number (f.Fd()). Then do an
os.Readlink(fmt.Sprintf("/proc/self/fd/%d", f.Fd()) and check the result
(if no error) with strings.HasSuffix(link, "(deleted)").
On Sunday, December 10, 2023 at 5:4
Not sure how you are detecting that the append it not working - it usually does
because a client can relink the inode to another file name using a syscall
I think what you want to do it either
1. Open the file exclusively so git cannot do this.
2. Check that the file create time is the same a
Thanks Jan.
Right. I'm familiar with the reference counting of files on unixies and the
default file locking on Windoze without specifying that sharing should be
allowed.
My use case is keeping a scientific notebook on disk. The notebook file is
(or should be!) append-only. And I'm trying very
On Sun, Dec 10, 2023 at 5:41 PM Jason E. Aten wrote:
> My question is: is there a way to have the Go process detect if the file it
> is writing to has been deleted by another process (git in this case) so that
> attempting to append to the file is no longer effective?
It is effective and [most
I'm debugging a weird situation where my open binary log file
has been deleted and replaced by an
identical copy by my doing a git commit (and maybe git rebase)
on it. The Go process is still running, still has the origional
file handle open, and is still "writing" to the
deleted log file to no e
