Lock file weird behavior

[HeyMyian]

Different behaviors observed (all on HDD):

• Lock file works as usual: is created upon opening project, would trigger a warning when opening the project twice, and is deleted upon closing the project.
• Lock file would not be removed after closing a project.
• Lock file would not be created after opening a project.
• Lock file would exist but not trigger the warning about its existence after opening a project once (When opened twice, it would trigger the warning). When closing the project, the lock file would be removed, or not removed.

After some testing with a new project I could only reproduce this issue on HDD, not on SSD.

[vkbo]

A few follow up questions:

• Is it with or without file sync enabled on the relevant folder?
• What OS and file system are we talking about here?
• If you run novelWriter from command line with the --verbose flag, are there any hints to what's going on in the log output?

[HeyMyian]

File system is NTFS on Windows 10. Is there a way to initiate --verbose on Windows?

This happens within a syncing Dropbox. I've figured out that for Dropbox the explorer lags behind (a bit) (sometimes) when it comes to displaying changed files -- so some of what I described above might not be relevant because I saw phantom files.

What does happen though is that the lock file sometimes isn't deleted. It just happened again with a new test project (filled with "example files"). I suspect Dropbox itself may be locking the file when it's syncing, preventing novelWriter from deleting it.

[vkbo]

You need to start novelWriter from command line, either from cmd or PowerShell, to see the logging output. You add --verbose as a flag there.

Yeah, I suspect this is a caching or file sync issue. As a Linux user, I find NTFS to be a really annoying file system to work with due to how it locks files. It's a daily struggle as I develop on Windows at work.

novelWriter will just ignore and keep going if it cannot do what it wants to the lock file, but the log output should show some warnings or errors. The lock file is just a safety feature so it can warn the user of a potential overwrite of the project file. In the event of an overwrite, only meta data is lost. It is not a risk to the text itself. Due to a previous issue related to file syncing, I implemented a check on text documents that the file it overwrites has not been altered since it was last saved. This is checked on every save, and should prevent unintended overwrites on text documents.

I don't know if there is a lot I can do to resolve this from my end. The file IO is handled by Python, and I've looked at the interface to see if there is anything I can do. Perhaps Dropbox gets confused as the file name is the same every time the file is created/deleted. Perhaps this can be resolved by adding a timestamp to the filename. I'll look into it.

[vkbo]

Is this issue still relevant? In novelWriter 2.x, the way lock files are handled have been rewritten, although they work roughly the same. I suspect this is an issue with file sync tools anyway, but I did find a small issue with lock files in the new implementation that may have caused a bleed-through between different projects, which I've now fixed.

[HeyMyian]

It's not relevant to me at least, since I'm not using Dropbox anymore (Nextcloud now) nor am I rapidly opening and closing the same project anymore. :shrug:

[vkbo]

Ok, I'll just close it then :)