Re: Lock file error

At this point I suspect there is a hidden system error when releasing
the lock. The lock is released simply by deleting the lock file and I
suspect the unlink syscall is failing but the failure is not reported.
Would you be able to test a debug build that I can prepare for you?


On Mon, 18 Dec 2023 at 19:05, Patrick Giasson <[email protected]> wrote:
>
> I'm sure my two roots are a stricly local folder and a remote one. If I touch a file locally, it doesn't appear automatically on the server. If I df the local folder, I get a /dev/sda3 response meaning it's on the local drive. No other syncing mechanism is used beside unison.
>
> Patrick
> On Saturday, December 9, 2023 at 7:50:45 AM UTC-5 Greg Troxel wrote:
>>
>> Patrick Giasson <[email protected]> writes:
>>
>> [The quoting on your message seems off; I've tried to repair it. I am
>> looking at the text/plain part.]
>>
>> >> Did you try ignoring .unison explicitly?
>> >
>> > I did in the latest test, as stated above with default.prf. Same error:
>> >
>> > Fatal error: Warning: the archives are locked.
>>
>> Are you sure that the directories are actually different, vs both being
>> remote mounts of the same thing? If you "touch .unison/foo" on the
>> local machine, does it appear on the server?
>>
>> My only other suggestion is to use ktrace (the BSD term, but the general
>> concept of strace/ktruss) to see which program is creating the lockfile
>> on the server. (I have no idea how to do this on Windows.)
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].