问题标签 [hfs+]

Mac 通常在规范化路径的 HFS+ 文件系统上运行。也就是说，如果您保存一个带有重音符号 é 的文件（u'\xe9'例如），然后执行 a os.listdir，您会看到文件名已转换为u'e\u0301'. 这是Pythonunicodedata模块可以处理的正常 unicode NFD 规范化。不幸的是，HFS+ 与 NFD 不完全一致，这意味着一些路径不会被规范化，例如福 ( u'\ufa1b') 不会改变，尽管它的 NFD 形式是u'\u798f'。

那么，如何在 Python 中进行规范化呢？只要我可以从 Python 调用它们，我就可以使用本机 API。

根据JLS，如果主机文件系统不支持 Unicode，则可以“修改”包含非 ASCII 字符的包名称。例如，包é变为@00e9，并且在投影到文件系统时papierMâché变为。papierM@00e2ch@00e9

问题是：对于 Java 源文件（其名称必须与 Java 类的相应名称一致）是否有可能实现相同的目标？

问题的背景是我需要在我的公共类名（'é'，'\u00e9'）中有一个带有尖锐的重音 e。是的，我知道我不应该，文件名中的 Unicode 是一种弊端，但我仍然需要它。

但是，无论是 Mac OS X 还是底层 HFS+ 文件系统都不允许在文件名中使用这个字符，而是将其替换为 'e' 后跟COMBINING ACUTE ACCENT( "e\u0301")。这种行为与 NTFS 或 ext3/ext4 完全不同，在 NTFS 或 ext3/ext4 中，两个文件命名"\u00e9"并"e\u0301"可以共存于同一目录中（测试存储库在此处）。

上述 HFS+ 行为导致 2 个问题：

1. 我无法编译我的类，javac因为类名和文件名不一样（尽管我可以使用Maven或ecj编译它们）。
2. 我不能用Git管理我的课程，因为它总是报告文件已被重命名：

.

由于 OSX Mavericks 支持文件标签。是否有任何 API 可以以编程方式访问这些？如何获取所有系统标签的列表？并操纵它们？

我已经试过了：

• NSFileManager 类
• 文件系统编程指南
• 文件元数据搜索编程指南

然而，这些都没有提到标签的存在。

我的来源是一个旧的外部硬盘驱动器，格式化为 HFS+（以前是来自运行 10.4.11 的服务器的数据），连接到运行 10.8.5 的 iMac，升级版本为 rsync 3.0.9。

目标是运行 rsync 3.0.9 的 Centos 6.4 服务器。

我们尝试将 FONTS 文件夹（源大小 = 4.7GB）传输到目标，但未保留文件夹的大小（目标大小 = 655MB）。以下是我为保留硬链接而运行的命令 - ACL .....

/usr/local/bin/rsync -aHpEXotg --devices --specials --ignore-errors /Users/london/Desktop/FONTS root@192.168.200.253:/home/TEST

也得到错误： rsync: rsync_xal_set: lsetxattr(""/home/TEST/FONTS/Folder/Kfz-EURO Schrift MAC+PC/MAC/FE Mittelschrift.image"","user.com.apple.FinderInfo") 失败：不支持操作 (95)

大多数文件显示为 Unix 文件，无法打开。这个问题一直很耗时，所以如果有人可以指导我。

谢谢..

We're working with a webdav server that interacts with Mac Finder. We've noticed that at least half of the requests that Finder makes when copying files and folders to the server involve several extra files:

• A .DS_Store file for each folder
• A ._filename resource fork for each file to be copied (including one for the .DS_Store)
• A .random-string-Spotlight file

I've noticed that if I return a 403 (Forbidden) response each time Finder tries to upload one of those files Finder won't complain, and the performance is greatly increased (more than 50%).

Now my questions are, how safe it is to just ignore those files? What kind of information I might be missing? What file formats will be rendered useless? etc.

Additionally, any other suggestion on how to improve the performance of this interaction is appreciated.

Thanks

我一直在寻找 Mac 计算机的 hfs 和 hfs+ 文件系统之间的区别，并找到了一些关于它们的信息，想知道是否 any1 可以为我提供一些资源来收集关于它们的一些信息，甚至为我提供一些关于它们之间区别的基本信息它们在复杂性、性能、使用的数据结构等方面。

事情是这样的，我需要调查这 4 个用于大学工作的文件系统，但我在网上找不到正确的信息

重点是比较这 4 个及其功能，但我找不到基准或详细数据

如果有人能告诉我你所知道的关于他们的优点和缺点的所有信息，或者任何有我需要的信息的网站，那就太棒了

非常感谢

问题：我需要剪切大波形文件。

我觉得应该有一种方法（或有可能创建它）将文件的某些部分移动到一个单独的文件中，几乎无需复制。那就是所有文件系统都使用集群并具有映射/列表来指出哪些集群属于哪些文件。该操作将指定一些集群指向一个新文件+尾部处理。

但我还没有听说过类似的 API。它们存在吗？

添加文件系统特定标签以吸引使用它们的人。

我目前正在使用 IOKit 开发一个虚拟 SCSI 设备驱动程序。我的驱动程序加载正常，我可以使用 ExFat、FAT32 或 HFS+ 格式化我的设备。

我还可以使用带有任何这些文件系统的 CLI 将文件复制到我的虚拟设备或从我的虚拟设备复制文件。使用 ExFat 或 FAT32，我还可以使用 Finder 从我的虚拟设备中复制或查看文件，但在驱动器格式化为 HFS+（日志式）时不能。

使用 HFS+ 时，我遇到与 Finder、Spotlight 或 Preview 相关的内核恐慌。例如，当系统在文件复制到磁盘后尝试预览文件时，就会发生这种情况。这是来自内核恐慌的示例日志：

这是上述恐慌日志的堆栈跟踪：

我很难确定问题，但如上所述已缩小到 HFS+。HFS+ 有什么特别的地方会导致这种情况吗？

由于问题与 VFS 和分页（？）有关，我开始怀疑我是否正确处理了 IOMemoryDe​​scriptors（我相信我是，基于我在 Apple 文档中读到的内容）。有人遇到过类似的问题吗？这通常表示特定类型的问题吗？

更新：我已经验证在 HFS+ 中禁用日志不会对上述结果产生影响。

UPDATE2：恐慌日志每次都是一致的。仅当满足以下所有条件时才会发生恐慌：

• 使用 HFS+
• 文件被复制到设备（对于单个文件 > 几 MB）
• 文件是使用 Finder 复制的（但不是终端，例如）

当第一个文件完成复制到设备时，内核始终会出现恐慌。可以复制许多等于或大于几 MB 的小文件而不会引起恐慌。我什至可以使用终端将文件大文件（> 30 MB）复制到卷中并在 Finder 中读取/打开它们。

I'm currently trying to write a script that does some post processing after rsync --max-size=4000000000 has done its job, to allow for full backups to FAT32 (which is the only filesystem that is r/w on all of Windows/Mac/*nix)

I am writing in bash for Mac OS X and Linux; currently testing on OS X. Code is here

https://github.com/taikedz/fullsync32/blob/master/fullsync32

The script recurses through directories finding

• files that have a resource fork (HFS property)
• files that are larger than 4 GB

and upon finding such files either processes them via tar -cz or split as appropriate, before copying them over.

I use recursion instead of the find utility because of the test for presence of resource fork on a file: it involves checking the size of a special file. Say you have file foo.txt; its resource fork can be found by looking at ls -l foo.txt/..namedfork/rsrc and cheking the length is non-zero.

The basic structure is

Problem

I ran this against my backups the other day and left it running for a few hours. When I came back I found that my spare 11 GB of RAM had been used up, and it was ~248 MB into swap...

I looked around on Google for issues around bash memory leakage in recursion, and apart from a few tenuously answered forum posts, didn't find much...

The other add result of which (which is Mac specific) is that the "Inactive memory" stays inactive and the system runs slowly... Restart required.

Questions

• Is such potentially deep recursion with bash a bad idea in itself?
• is there an ingenious way to iterate rather than recurse in this situation?
• or am I going about this completely wrong anyways?

You inputs are much appreciated!