Perforce文件大小与光盘上的不同

我们看到一个奇怪的行为，一个用户将一个文件推送到perforce。磁盘上的原始文件是

393846

字节，其中提交到perforce后的文件变成了

393382

。那么丢失的464字节去了哪里

额外详情：

• 所有各方窗口
• 资产类型：二进制（非真实资产）

---

在服务器上，文本文件被规范化为以LF结尾的行（也称为“unix样式”）。在单个客户端上，文件以本机格式呈现，这意味着在Windows上以CRLF终止的行

因此，如果从Windows客户端提交一个包含464行的文件，那么当它存储在服务器上时，它将减少464个字节，因为所有CR字节都将被删除。当它同步回Windows客户端（任何Windows客户端）时，CRs将被放回。下面是一个这样的例子：

C:\Perforce\test\python>p4 fstat -Ol text.txt
... depotFile //collaborators/main/python/text.txt
... clientFile c:\Perforce\test\python\text.txt
... isMapped
... headAction edit
... headType text
... headTime 1595542603
... headRev 4
... headChange 181
... headModTime 1595542590
... haveRev 4
... fileSize 148
... digest A6A7BF7DF3274FAA12F6BC394DFC2C69


C:\Perforce\test\python>dir text.txt
 Volume in drive C is OS
 Volume Serial Number is AE05-0B05

 Directory of C:\Perforce\test\python

07/23/2020  03:16 PM               157 text.txt
               1 File(s)            157 bytes
               0 Dir(s)  789,006,692,352 bytes free

C:\Perforce\test\python>wc -l text.txt
9 text.txt

请注意，

fstat-Ol

返回的

fileSize

为148字节，而

dir

返回的本地文件大小为157字节；9个字节的差异是因为

头类型

是

文本

（也由

fstat-Ol

显示），文件长9行，如

wc-l

所示

正如Bryan在评论中指出的，关键字扩展也可以解释从客户端提交的内容与服务器上的内容之间的差异，尽管在这种情况下，客户端文件将被刷新，以便在提交完全完成后，客户端和服务器端文件将具有相同的关键字内容和大小（不考虑前面提到的行结束翻译）

如果文件的

unicode

类型也可能导致差异，因为unicode文件在服务器上被规范化为UTF-8；例如，如果一个UTF-16文件主要包含具有单字节UTF-8表示形式的字符，那么它在服务器上最终会变得更小

---

对于具有

二进制

类型的文件，我不希望客户端上的大小与服务器上的（预压缩）大小之间存在差异。

文本文件在服务器上被标准化为以LF结尾的行（也称为“unix样式”）。在单个客户端上，文件以本机格式呈现，这意味着在Windows上以CRLF终止的行

因此，如果从Windows客户端提交一个包含464行的文件，那么当它存储在服务器上时，它将减少464个字节，因为所有CR字节都将被删除。当它同步回Windows客户端（任何Windows客户端）时，CRs将被放回。下面是一个这样的例子：

C:\Perforce\test\python>p4 fstat -Ol text.txt
... depotFile //collaborators/main/python/text.txt
... clientFile c:\Perforce\test\python\text.txt
... isMapped
... headAction edit
... headType text
... headTime 1595542603
... headRev 4
... headChange 181
... headModTime 1595542590
... haveRev 4
... fileSize 148
... digest A6A7BF7DF3274FAA12F6BC394DFC2C69


C:\Perforce\test\python>dir text.txt
 Volume in drive C is OS
 Volume Serial Number is AE05-0B05

 Directory of C:\Perforce\test\python

07/23/2020  03:16 PM               157 text.txt
               1 File(s)            157 bytes
               0 Dir(s)  789,006,692,352 bytes free

C:\Perforce\test\python>wc -l text.txt
9 text.txt

请注意，

fstat-Ol

返回的

fileSize

为148字节，而

dir

返回的本地文件大小为157字节；9个字节的差异是因为

头类型

是

文本

（也由

fstat-Ol

显示），文件长9行，如

wc-l

所示

正如Bryan在评论中指出的，关键字扩展也可以解释从客户端提交的内容与服务器上的内容之间的差异，尽管在这种情况下，客户端文件将被刷新，以便在提交完全完成后，客户端和服务器端文件将具有相同的关键字内容和大小（不考虑前面提到的行结束翻译）

如果文件的

unicode

类型也可能导致差异，因为unicode文件在服务器上被规范化为UTF-8；例如，如果一个UTF-16文件主要包含具有单字节UTF-8表示形式的字符，那么它在服务器上最终会变得更小

---

对于具有

binary

类型的文件，我不希望客户端上的大小与服务器上的（预压缩）大小之间存在差异。

详细信息，请！关于操作系统、软件版本文件类型、您如何进行这些测量、您已经调查过哪些可能的理论等信息都是需要的。我的猜测是，你有一个Mac或Windows客户端，这种差异是由于行端编码的差异造成的。另一种可能是RCS关键字扩展。但是你必须提供更多的信息才能弄清楚到底发生了什么。嘿@BryanPendleton试图添加更多的细节。还有什么需要的吗？看看你从中得到这些信息的实际输出就好了。我将在我的答案中添加一个示例，这样您就可以看到这些信息是什么样子的，如果您有一个尚未涉及的案例，可以将其添加到您的问题中。请提供详细信息！关于操作系统、软件版本文件类型、您如何进行这些测量、您已经调查过哪些可能的理论等信息都是需要的。我的猜测是，你有一个Mac或Windows客户端，这种差异是由于行端编码的差异造成的。另一种可能是RCS关键字扩展。但是你必须提供更多的信息才能弄清楚到底发生了什么。嘿@BryanPendleton试图添加更多的细节。还有什么需要的吗？看看你从中得到这些信息的实际输出就好了。我会在我的答案中添加一个例子，这样你就可以看到这些信息是什么样子，如果你有一个尚未涉及的案例，可能会将其添加到你的问题中。我想这是有意义的，我有时间再次检查文件，还有一些

.uassets

作为performe文件类型

text

是否有办法告诉performe

.uassets

始终是二进制的？您可以使用

p4 typemap

来配置服务器对文件类型的选择：我想现在有意义了，我有时间再次检查文件，还有一些

.uassets

作为performe文件类型

text

是否有办法告诉performe

.uassets

始终是二进制的？您可以使用

p4