filesystem: document hard-link behavior and report the link count in get_file_info
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 72/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- node.js, typescript
- 领域
- backend, documentation
调研方向
Start with src/filesystem/README.md around line 106 and the filesystem server implementation of get_file_info. Check how write_file and edit_file handle existing files, then find the fs.stat result used for file information. Add the README explanation, expose nlink, and cover the field in tests; the changeset should describe the new output field.
由索引模型根据 Issue 内容生成。
描述
The filesystem server's README should spell out what hard links mean for reads and writes, and get_file_info should report a file's link count.
Problem
write_file and edit_file overwrite an existing file in place, and the README says so (src/filesystem/README.md:106: the file "keeps its inode, creation time, hard links and permissions"). It does not spell out the consequence: when a file inside an allowed directory is a hard link to a file elsewhere, both names are the same file, so an overwrite changes the content seen at every name, and a read returns that shared content. Some tools create hard links routinely (pnpm's content-addressable store, for example, hard-links package files into node_modules), so this can happen without anyone choosing it.
The server cannot currently tell a caller whether a file has other names: get_file_info does not report the link count.
Expected
- A README paragraph, under
write_file(or in a short note on allowed directories), saying that the server's allowed-directory checks are path-based, that a hard link is a real name of the same file, and that overwriting or editing such a file changes it at all of its names. get_file_inforeports the link count (nlinkfromfs.stat), so a client or model can see that a file has more than one name before changing it.
Tests for the new get_file_info field, and a changeset (minor: a new output field).
- 主要语言
- TypeScript
- 星标
- 91.6k
- 派生
- 11.9k
- 平均合并
- 6 小时 37 分钟
- 30 天内合并 PR
- 147
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/servers 的其他 Issue
-
chore v2
难度 2/5 1-3 小时 新手友好度 83/100
modelcontextprotocol/servers#5261 ·
维护者通常 1 天内回复
-
docs(git): clarify unconfined default scope and repository confinement options in README and CLI未关闭
难度 2/5 1-3 小时 新手友好度 73/100
modelcontextprotocol/servers#5231 · 1 条评论 ·
维护者通常 1 天内回复
-
docs(git): clarify unconfined default scope and repository confinement options in README and CLI未关闭
难度 1/5 1 小时以内 新手友好度 74/100
modelcontextprotocol/servers#5230 ·
维护者通常 1 天内回复
-
git: README should state plainly that without --repository every reachable repository is in scope未关闭documentation server-git v2
难度 1/5 1-3 小时 新手友好度 84/100
modelcontextprotocol/servers#5225 · 1 条评论 ·
维护者通常 1 天内回复
-
chore v2
难度 2/5 1-3 小时 新手友好度 82/100
modelcontextprotocol/servers#5223 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/servers 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
awslabs/visual-asset-management-system#804 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
restatedev/sdk-typescript#813 ·
-
bug desktop P1 session XS
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
Merit-Systems/x402scan#1312 ·
-
type:bug
难度 2/5 1-3 小时 新手友好度 78/100
Azure/apiops-cli#331 ·
维护者通常 3 天内回复