zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

After reviewing this proposal again I'm still worried about direct
multi-user usage. Locking single files seems doable, but I see
problems e.g. when you move a file and want to update links in X other
files. Would you need to lock all these files before proceeding ? If
so, lot of code needs to be touched.

Easier option is a single lock per notebook, but that essentially
enforces a single editor at a time, so not multi-user at all.

-- Jaap

On Thu, Mar 1, 2012 at 8:36 PM, Jaap Karssenberg
<jaap.karssenberg@xxxxxxxxx> wrote:
> On Thu, Mar 1, 2012 at 8:18 PM, João Santos <jmcs@xxxxxxxxxx> wrote:
>>
>> Apparently renaming a directory is atomic on windows if you can guaranty
>> that the destination name doesn't exist, so I think we can use that to
>> ensure that the lock is removed atomically, if we use the an uuid based name
>> as the destination name, and removing it after that.
>
>
> Agreed, so to summarize:
>
> When creating a lock, we need to create the directory first under another
> name, and then rename it to the lock directory. If someone tries to do the
> same at the same time, one of both should fail because the lock already
> exists.
>
> For remove we need to do the opposite, move it to another name, than delete
> it.
>
> Creating a folder, than the file, or first deleting the file, than the
> folder, could leave an empty folder if we crash in between the two actions.
>
> Becomes quite involved, so think we need to hide this from the user,
> probably I will put the locks in a ".locks" folder in the notebook folder to
> keep them out of sight.
>
> Maybe when zim initializes, we should do a cleanup of empty folders than are
> older than X minutes (so crashes get cleaned up).
>
> Also I would say re-touch the lockfile every few minutes, so if we want to
> acquire a lock, and the file is older than X hours, we just break it without
> bothering the user.
>
> Regards,
>
> Jaap
>