0 票
229 次浏览

(Posted by Stephen Lilley)

I got the following messaged during backup to a file using Paratext 7.5 Linux version.

"The following files had naming conflicts and were not backed up

/home/myname/ParatextProjects/NTLadTr/usfm.sty

/home/myname/ParatextProjects/NTLadTr/eng.vrs

If you do not wish to see this message again, delete these files"

I’ve never had this error before during backing up to a file in Paratext 7.4 Linux version. Why would it appear now? Is there a bug with the program during backing up or there is an issue with the naming?

较早的帖子 - 以原始语言显示
Paratext 中 由 发布 | 229 次浏览

1 个回答

0 票

(Answered by Thomas Hindle)

Paratext itself, as far as I can tell, hasn’t had any significant updates in this area between PT 7.4 and PT 7.5.

So I suspect that if you ran 7.4 in the current situation it would yield the same warning message.

I suspect the problem occurs because of file case differences. I examined project NTLadTr (The latest copy S/Red on “Mon, 01 Dec 2014 07:56:10 +1100”) and it did not seem to have any file case problems with either usfm.sty or eng.vrs.

So I suspect that if you look in: /home/myname/ParatextProjects/

a usfm.sty and eng.vrs will exist but with differing case. (IE. not all lowercase)

What to do about it:

  1. If a single file exists in /home/myname/ParatextProjects/ of usfm.sty and eng.vrs but not in all lowercase then simply rename it to a lowercase. Or
  2. If multiple files exist in /home/myname/ParatextProjects/ of usfm.sty and eng.vrs with differing case then delete (or backup and delete) the files not in all lower case.

What caused this: I can’t say for sure but It could have been a new resource that was installed that wrote a copy of usfm.sty with the wrong case. There is logic in PT that tries to protect against this, but its possible that doesn’t deal with all cases.

If you can see a reliable way to reproduce this problem, something like Install Resource X then run backup on Project Y, I would be interested to know so PT can be made more robust against this.

较早的帖子 - 以原始语言显示
由 发布

相关问题

0 票
0 个回答 168 次浏览
I've wondered if we ought to write something about shared projects and backup software. Users may be using a ... /tiki-index.php?page_ref_id=376 I'd appreciate any comments.
[Expert]
sewhite
3.3k 发布
提问于 一月 28, 2016
0 票
0 个回答 173 次浏览
当我们的项目处理圣经模块时,我们在 XXC 书中频繁遇到合并冲突 但这些 冲突 实际上是与原始位置的编辑相关的问题 有时这与原始引用位置的冲突相对应,但其他时候,它似乎仅仅是由于特定用户何时打开其 XXC 书并因此刷新 ... ]] 我正在考虑撰写一份错误报告/功能请求,但我也在 wondering 是否有关于系统的某些方面是我 simply 没有理解的
mnjames 1.9k 发布 提问于 二月 5, 2022
0 票
3 个回答 310 次浏览
我们翻译团队正在使用 Paratext,并通过 Paratext Live 连接了 4 台电脑 有几个地方,两名团队成员在非共同工作时间对同一节经文进行了编辑,因此这些位置出现了红色的小冲突三角形,以提示存在冲突 然而,当我们通过 ... 按钮 这是正常的工作方式吗?我以为如果我解决了,其他人就不需要再操作了? 感谢提供任何建议 anon110449
anon110449 114 发布 提问于 六月 17, 2021
0 票
2 个回答 373 次浏览
由于未知原因,我们在几个章节的空节上出现了冲突。 除了逐个处理之外,有没有什么方法可以清除它们?
listentwice 1.2k 发布 提问于 五月 14, 2021
0 票
5 个回答 357 次浏览
我有一个测试项目,其中有多人拥有写入权限(有点混乱),在两个人并行创建了一些新书之后,我遇到了数千个冲突。有没有办法批量解决它们?
jeffh 1.4k 发布 提问于 十二月 2, 2020
Welcome to Support Bible, where you can ask questions and receive answers from other members of the community.
May the God who gives endurance and encouragement give you the same attitude of mind toward each other that Christ Jesus had.
Romans 15:5
3,053 个问题
6,013 个回答
5,677 条评论
2,032 位用户