Moving novels between PC's and platforms

[dgoadby]

I have just found novelWriter after suffering Bibisco's quirks for long enough.

I have started to build my novel using cut and paste from the previous application and no problems so far except quite a few startup warnings saying "WARNING Duplicate handle encountered! Retrying....". It seems happy so I'm not worried at this time.

This is my question: I use a Linux laptop and a Windows PC. Can I just copy the novel folder across between the two platforms?

My guess is "yes" providing novelWriter points to the correct novel folder, backup folder and has permissions but I haven't dug too deep into the Python to check. I will be contributing for sure!

[vkbo]

There is the matter of Unix vs Windows line endings. novelWriter uses Unix line endings internally, and everything else is handled by the Python file IO library. I've never tried to work on the same project across Linux and Windows, but it should in principle work fine.

As for the duplicate handle warning, the mentioned handle is the hash value that is assigned to a file or a folder when you create it. The handle is generated by sha256-hashing the internal clock, and if you create many at the same time, there may be conflicts if the clock's time resolution is low. The conflicts are resolved by just generating a new handle, so it isn't a problem. It happens frequently in the test suite for instance.

I'm a bit puzzled that this happens with regular usage, and it shouldn't happen during regular startup. Are you certain the warnings didn't occur when you created a new project? That's the only time these handles are generated rapidly.

[vkbo]

I just created a new project with over 100 files, and got no warnings about handles. I'm on Linux, so the time resolution of the clock is in the microsecond range. However, trying the same on Windows, I got lots of such warnings. I suspect that this is indeed due to time resolution. On Windows the resolution seems to be on the order of 10 milliseconds, which is certainly long enough to generate duplicates. In any case, the warnings can safely be ignored.

[dgoadby]

With reference to the duplicate handle problem I can confirm that this occurs on my Windows 7 system. I just recreated the problem a few times and it consistently only happens when you create a new project and select "Show detailed options for filling the project". It does not occur, at least on Windows 7, if you select "Fill the project with example files".

With reference to cross-platform use Python 2 had a universal line end mode and I am sure that Python 3 has a similar mode if text files are opened with the parameter "newline=None". I haven't checked the code and will try it later today and report back.

[vkbo]

If you create an example project, no new files are created. It just extracts the repository's sample project zip file into the folder you specify, so no new handles are generated.

I created an issue #769 to fix the warnings, as I try to eliminate warnings during regular usage (unless they're triggered by direct user action). I've had the practice of adding if-statements to capture unintended actions and write warning and error messages to the logging object, and instead of removing the warnings when the code is stable, ensure that during regular use, no such warnings are produced. It has helped me tighten up a lot of logic in the code.

As for the line endings, it works fine for the sample project on Windows, which is saved in the source code with Unix line endings, so I know Python handles this transparently. I just haven't tested the other way around when mixing both modes in the underlying text files of each project document. Presumably it should work fine, but it will probably generate a lot of diffs whenever the file is saved on alternate platforms as all line endings are replaced.

I have considered overriding the newline parameter, which you mention, and hard code it to \n, but it would mean that opening the raw files on a Windows computer in for instance notepad would potentially mess up the files.

In any case, Python does a good job of handling the OS differences so the programmer can ignore them. There are very few os-specific if-statements in the code, and mainly they are for macOS.