MoreRSS

site iconTjSky | 秋风于渭水修改

90后。编程爱好者。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

TjSky | 秋风于渭水的 RSS 预览

如何正确拉取超大体积的git项目——开发小技巧

2025-05-14 15:48:33

最近遇到一个体积相当大的仓库(40GB+),结果在安利给群内小伙伴时,很多人遇到了直接使用 git clone 克隆仓库到本地时,对本地网络的稳定性有巨大挑战,一旦网络波动导致传输中断,就只能从头下载。
很多人拉项目时习惯git clone一把梭哈,这并不是一个很好的习惯,众所周知国内访问github属于玄学,而且有些项目非常大,搞不好需要好几个小时才能拉取完,长时间+不稳定的网络,很容易出意外。本文就是介绍两种应对超大体积项目的拉取的办法「Git LFS」和「Git fetch」。


Git 的 git clone 命令本身是不直接支持断点续传的,git clone 本质上是创建一个新仓库,并一次性拉取远程所有数据(包括提交历史、分支、标签等)。如果中途中断本地目录会处于不完整状态,直接重试 git clone 会失败,如果你退出终端本地目录也会被清空。

使用 Git Large File Storage(Git LFS)

简单介绍一下 Git LFS

Git Large File Storage(Git LFS)是一个用于管理大型文件的Git扩展工具,旨在解决Git原生对大文件支持不足的问题。

Git LFS 优点

  • Git LFS用轻量级文本指针(如oid sha256:…)替换实际大文件,避免仓库臃肿。
  • 大文件内容存储在专用服务器(如GitHub LFS、块储存、自建储存、CDN),仅按需下载。
  • 支持单个文件GB级别存储,突破Git对文件大小的限制。(比如 github 是单文件小于100MB,单文件大于50MB会出现警告)
  • 因为大文件实际是分离储存的,可以优化拉取速度。
  • 安装Git LFS 并配置好后,日常 git 操作时,几乎是无感的,Git LFS 会自动处理大文件。

Git LFS 缺点

  • 需要项目创建者配合从一开始就使用 Git LFS,如果项目没有采用,对于想要克隆拉取项目的人是没有办法去使用 Git LFS 的。
  • 额外的大文件储存和下载都是需要开发者额外掏钱的,像是GitHub就只有10 GiB的免费空间和流量可用,超过的部分需要额外收费。(如果你是pth之类的AI模型文件,huggingface之类的平台给了免费的 LFS 空间)

不要 git clone 一把梭哈,改用 git fetch 分步拉取

简单介绍一下 git fetch 分步拉取

Git LFS 更多面对的是项目中部分文件体积很大的情况,比如Unity项目中的.asset文件、PSD源文件、CSV数据集。但还有一种情况,项目中每个文件体积都不大,可能只有几兆到十几兆,但是项目中文件数量极多,几百上千个,加到一起后整个项目体积也到了 GB 规模。这个时候更适合分步拉取的方式。

和 git clone 相比 git fetch 的优势

  • git fetch 基于 Git 对象模型,天然支持断点续传。
  • 即使多次中断,只要本地 .git 目录未损坏,均可通过反复执行 git fetch 逐步补全数据。
  • 如果中断期间远程仓库新增了提交,git fetch 会同时下载新增内容和未完成的旧内容,最终保持本地与远程一致。

和 git clone 相比 git fetch 的缺点

除了操作稍微多了几个步骤,没任何额外的缺点。

git fetch 分布拉取的方法

  1. 先手动创建空仓库并构建.git文件
mkdir your-repo && cd your-repo
git init
git remote add origin https://github.com/user/repo.git
  1. 分步拉取数据
git fetch origin --progress  # 如果中间传输中断,就在目录下再执行一次这个命令即可。
  1. 等待拉取完毕(以下仅为举例,请根据实现终端显示为准),这时候项目所有内容都会被打包在.git/objects/pack目录下的.pack文件内。
Resolving deltas: 100% (9999/9999), done.
From https://github.com/user/repo.git
 * [new branch]      master     -> origin/master
 * [new tag]         v1.0       -> v1.0
 * [new tag]         v1.1       -> v1.1
 * [new tag]         v1.2       -> v1.2
 * [new tag]         v2.0       -> v2.0
 * [new tag]         v2.1       -> v2.1
 * [new tag]         v2.2       -> v2.2
 * [new tag]         v2.3       -> v2.3
 * [new tag]         v2.4       -> v2.4
 * [new tag]         v3.0       -> v3.0
  1. 将需要的分支检出,比如我们检出 master 主分支。
git checkout master
  1. 其他优化建议

使用浅克隆减少首次下载量,比如只拉取最新分支

git clone --depth 1 https://github.com/user/repo.git

之后再补全历史(或者就干脆不补全,节约点空间)

git fetch --unshallow

总结

总的来说 Git LFS 主要是应对项目中出现几个巨大体积文件的情况,git fetch 主要是应对一次开机无法完成下载的超大型仓库或不稳定网络环境,比直接 git clone 一把梭哈更加灵活。

PS:顺带提一嘴,如果多次中断和重新拉取,可能会在.git/objects/pack目录下出现很多个.pack文件。如果需要清理的的话,在项目目录下执行git gc --auto
再PS:不用在意.pack文件的巨大体积,因为工作目录下你看到的具体文件,是通过硬链接、符号链接构建的,工作目录内的文件和 .pack 中的对象共享同一份数据,并不会真实占用双倍物理空间。实际占用大概是1.2~1.3倍空间,因为.pack文件还是有一定的压缩的。

The post 如何正确拉取超大体积的git项目——开发小技巧 appeared first on 秋风于渭水.

GitHub 阻止中文用户访问了 吗?(附临时解决方案)

2025-04-29 14:43:46

引言

今天群里不小小伙伴都表示在访问 GitHub 时遇到了「对本网站的访问受到限制」 (access to this site has been restricted) 、「访问已被限制」(Access has been restricted)的提示。

之前 GitHub 曾因失误部署了屏蔽所有中国 IP 地址的规则,中国 IP 地址访问时会出现禁止访问提示,之后 GitHub 更新了规则,中国 IP 地址重新可以访问了。GitHub 给出的解释当初是部署错误。

如果之前是失误那现在肯定就是故意的了,这次如果你使用代理访问,并且使用的是中文 (仅限 zh_CN),那么你就有可能被 GitHub 阻止访问。



情况

那么问题来了,GitHub 是打算主动屏蔽所有中国用户吗?
经过我和群内小伙伴们的测试,答案是:应该不是,看起来更像是 GitHub 针对中文爬虫设定的反爬措施。

实际触发这个限制的条件逻辑是:
1. 基于IP或者UA等判断(比如是不是机房IP,代理IP,常见爬虫UA,模拟浏览器头)
2. 基于一些流量模型判断(比如访问频率过高,访问范围过广)
3. 是不是请求头的语言部分包含 zh_CN
4. 只有上边每一层检测,都触发了“是”,那么才会触发访问限制。
5. 并且这个限制是分功能的,不是完全不可用,有可能你可以在浏览器中浏览项目,编辑文件,但你这时却无法在 浏览器内 raw,无法在终端里 git clone。

也就是说,对于正常的中文用户,如果你的IP比较干净,不是使用奇形怪状的浏览器访问,都是可以正常访问 GitHub 的。

碎碎谈

感觉 GitHub 大概率是为了反爬虫、反抓取,毕竟现在 AI 训练爬虫在对 GitHub 疯狂抓取用来训练模型。微软虽然家大业大也没钱了嘛。不过国内爬虫是有多少啊,都能让 GitHub 把语言当作一个过滤条件了。之前那次屏蔽中国IP,搞不好起因也是这个,只是个某个管理错误的把中国的IP段全部给拉黑了。
不过把请求头语言项作为爬虫检查项,意义不大吧,这个特征也不难改……

如果你使用的代理 IP 质量不佳,IP 被万人骑,实在太黑了,导致被 GitHub 拦截了,比较简单的办法就是:
– 换个IP
– 使用一些浏览器请求头修改扩展,将请求头语言部分改成 accept-language = en_US,en;q=0.9,zh;q=0.8 (英语优先,中文备选)。
– 直接去浏览器设置里修改网页首选语言(所有网页都会收到影响,比如不登录状态下谷歌和bing就会给你返回英文网页和英文搜索结果优先了)

以Header Editor 4.1.1 为例,修改请求头

启用请求头修改前,部分位于https://camo.githubusercontent.com的图报HTTP429「Access has been restricted」

启用请求头修改后,马上恢复正常。

The post GitHub 阻止中文用户访问了 吗?(附临时解决方案) appeared first on 秋风于渭水.

WIN11更新后,C盘下莫名多出的神秘空文件夹inetpub不是BUG,不要删

2025-04-17 10:05:18

微软明确说明 Windows 11用户在安装4月累积更新(KB5055523)后,不能删除系统创建的“inetpub”文件夹!!如果已经删了,需要按步骤恢复这个“inetpub”文件夹,以提高系统安全性。


最近很多人在安装微软发布的 Windows 11 4月累积更新(KB5055523)后,发现系统C盘根目录下神秘出现了一个名为 “inetpub” 的空文件夹。当时大家一致认为这又是伟大的阿三程序员写出新bug了。

“inetpub” 文件夹通常是微软 Internet 信息服务 (IIS) 创建的,IIS 是微软推出的 Web 服务器软件,用于在Windows 11上托管网站或应用程序,一般情况下只有在启用 IIS 后根目录才会出现 “inetpub” 文件夹,但在此次更新中,即使用户未启用 IIS 该文件夹也会自动创建。看起来十分不正常,于是大家都认为这是个 bug。

于是很多科技博主都表示 “这个 “inetpub” 文件夹可以删除,本身这个文件夹也是空的,测试删除后不会对系统造成任何负面影响”,我也受不了C盘有个陌生文件夹,就给删了,结果尴尬了……

但其实这个操作是为了修复漏洞“CVE-2025-21204”的,估计微软没想到大家会如此在意系统根目录出现陌生文件夹,在更新日志中压根没提到会有这个操作,考虑到用户删除“inetpub”后会影响系统安全,微软最近又更新日志添加了这个文件夹的说明

注意:直接手动重建这个文件夹对修复漏洞“CVE-2025-21204”是没有作用的!需要按正确步骤恢复

恢复方式一:
1. 点开开始菜单
2. 在搜索框里搜索开启或关闭 Windows 功能并打开
3. 勾选 IIS 服务 (Internet Information Services) 并点击确定
4. 等待 1、2 分钟 IIS 服务会完成安装,此时会自动创建“inetpub”文件夹
5. 随后关闭 IIS 服务

恢复方式二(微软的推荐做法):
1. 设置 → Windows更新 → 更新历史记录
2. 拉到底,选「卸载更新」
3. 找到 「用于Microsoft Windows的安全更新(KB5055523)」,点击卸载,等待卸载完毕后,重启电脑
4. 重启后,再次检查系统更新,并重新安装「适用于 Windows 11 Version 24H2 的 04 累积更新,适合基于 x64 的系统 (KB5055523)」即可自动恢复“inetpub”文件夹。

The post WIN11更新后,C盘下莫名多出的神秘空文件夹inetpub不是BUG,不要删 appeared first on 秋风于渭水.

Claw Cloud Run 免费容器来了,无需信用卡,Github账号满180天,终身每月送5$

2025-04-16 15:20:54

Claw Cloud Run是 Claw Cloud 旗下的轻应用平台,你可以理解成 Vercel、Netlify 之类的东西,既是 PaaS 平台,也有 Serverless 服务,还能跑类 Docker 项目(不是直接用 Docker 跑的,是自动适配,用 Serverless 形式跑的),可以快速部署 Alist、Rsshub、Memos、Uptime Kuma、Chatgpt-next-web等程序。甚至可以用来跑 Minecraft 游戏服务器,注册即送 5 刀额度,如果绑定一个注册超过180天的 Github 账号可以永久享受每月5美元的额度。每个可用区有4H 8G 10G 资源,一共 10 GB 流量。


有白嫖自然是很开心的嘛,虽然Vercel也挺好用的,但是Claw Cloud Run还有免费的数据库可用,跑一些个人项目会更加方便一点,最主要是,新加坡区和日本区到国内的速度相当不错:

注册页链接 (有AFF)

如果不想走我的AFF的话,自己谷歌一下「Claw Cloud Run」就能找到官网了。

使用注册超过180天的github账号登录的话,可以享受每月5刀的赠送,不需要信用卡。
如果没有的话,则只会赠送一次5刀的额度。

注意:每月送的5刀的账户,还是免费计划而不是爱好计划。送你的5刀是让你抵扣使用费用的。
根据页面上的预计费用,Alist 每天0.04刀,WordPress 每天0.06刀,通过适当自行缩小容器配置,算下来每个月免费部署4、5个自用项目还是没问题。

如何缩小容器配置

默认他一个项目最小给1H1G,对于有些小项目,实在太奢侈了,适当改小可以有效降低部署费用。
我有个给贴吧自动签到的脚本,这玩意本地跑才占用几M好不,所以我只给了0.1核64M内存。每天仅需1分钱(其实用不到的,只是因为显示上最小差值是 0.01元)。

  1. 进入应用列表
  2. 点进需要修改的项目
  3. 左上角有个「Update」,点进去
  4. 愉快的把CPU和内存改小就好了。

PS: Claw Cloud(阿爪云,又名阿里云青春版)小道消息称,这是阿里云在新加坡开的马甲(因为他们基础设施都是用的阿里云的)。不过也有一种可能是基于阿里云的二道贩子在蹭热度,这在云服务提供商中也并不少见。

友情提醒
1. 目前 Claw Cloud 的 Janpan 和 Singapore 非常拥挤,随便一个项目开机都要好几分钟,请尽量避开日本和新加坡区。
2. 他家服务稳定性比较,嗯,最近可能人多,有点炸裂,如果项目出问题了,请重启项目解决。

The post Claw Cloud Run 免费容器来了,无需信用卡,Github账号满180天,终身每月送5$ appeared first on 秋风于渭水.

谷歌这是在干啥?强制给我开个广告拦截收入挽回?

2025-03-23 11:47:56

我也没开广告拦截收入挽回啊,谷歌就偷偷通过扩展静默注入广告拦截收入挽回代码了?
我对大家拦截站内广告的态度是:不喜欢看那就拦截掉,不想看广告是用户的权利。

开始我还以为谷歌这是广告营收下滑了,着急了。
结果去查了一下。啥,营收反而涨了?
哦,不会就是靠这种方式涨的吧

随后我再仔细一看,好嘛
反反广告拦截收入挽回也被自动注入了
去广告拦截器拦截了广告拦截收入挽回会被检测

但问题是,我压根就没开这个功能,adsense 内这个选项也是关闭状态,这完全是谷歌自作主张自行强制加入的。

从“不作恶”到“做正确的事”
从“技术导向”到“资本导向”
谷歌公司正在向下一个波音公司一路狂奔……

The post 谷歌这是在干啥?强制给我开个广告拦截收入挽回? appeared first on 秋风于渭水.

如何快速批量检索损坏的图片文件—python开发学习笔记(一)

2025-03-19 20:20:36

为了解决几十万量级图片库内异常图片的检测,折腾出了一个基于 python 的图片检测程序。


一、混乱的图片仓库

用前一段发现的本地 AI 图片视频搜索引擎 MaterialSearch 整理十几年间积累的几十万张图片时,遇到了一个令人崩溃的场景:有上百张图片报损坏,经过部分核查,很多文件打开后呈现诡异色块,亦或者只有半截图,还有些文件大小为 0 KB。这些损坏的图片零散的散布在数千个子文件夹中,手动一个一个检查无异于大海捞针,累死也搞不定。于是 VS code 启动!!


二、初版方案

用 Pillow 暴力验证,直接用 Pillow verify()看看是否报错来解决。

代码V1.0方案(基础检测逻辑)

from PIL import Image

def check_img_v1(path):
    try:
        Image.open(path).verify()
        return True
    except:
        return False

V1.0方案的情况
1. 误报文件:很多图片会报损坏,但是用图片浏览器打开却十分正常,经过研究之后才知道,原来大量网站在使用一种叫做渐进式JPEG的技术,通过将图像数据分为多个扫描逐层渲染,可以在网速不好时图片先绘制出低分辨率的模糊轮廓,随着数据被下载逐步变为清晰图像(现代图片编码如WEBP、AVIF也都有类似的渐进式加载机制)。这导致需要完整解码才能验证所有扫描数据。因此被verify()误认为损坏。
2. 漏检文件:未完整下载的图片有时也能通过验证。
3. 性能问题:慢,按照测试计算,10万张图片的检测起码需要耗时4、5小时了。


三、改进方案

经过对 MaterialSearch 日志报错图片的抽查,发现损坏的文件主要是文件不完整导致的半截图,于是我打算改为:先检查文件结尾是否存在结束符来判定图片是否损坏,然后再做进一步检查。

代码V2.0(尾部校验部分代码)

def check_img_v2(path):
    with open(path, 'rb') as f:
        f.seek(-32, 2) #只用获取文件最后32字节就行
        trailer = f.read()
        if path.lower().endswith('.jpg'):
            return trailer.endswith(b'\xff\xd9')  # JPEG的结束符
        elif path.lower().endswith('.png'):
            return trailer.endswith(b'\xaeB`\x82')  # PNG的IEND块

V2.0方案的情况
1. 捕获到了异常文件 :下载一半的文件确实被检测出来了。
2. 检测了个寂寞 :如果图片附加了元数据,图片文件很可能就不是以\xff\xd9结尾了,结果就是1000张的测试图片,在尾部检测部分逻辑,有800多张都报了损坏……想快速检查了个寂寞。


四、再次优化

使用img.load() 强制加载所有数据。对渐进式jpeg图片做特殊处理逻辑。

代码V3.0(验证部分的修改)

def check_img_v3(path):
    try:
        with open(path, 'rb') as f:  
            img = Image.open(f)
            img.load()  # 强制加载完整图片

            # 特殊处理渐进式JPEG
            if img.format == 'JPEG' and 'progressive' in img.info:
                img.tile = []  

            return True
    except Exception as e:
        print(f"损坏文件: {path} | 错误类型: {type(e).__name__}")
        return False

V3.0方案的情况
1. 漏报率下降了很多
2. 渐进式JPEG兼容处理
3. 打印异常类型方便处理
4. 实际代码中自己傻逼了在verify()之后调用load(),导致文件指针不可用,说人话就是:代码逻辑中verify()做完检查后,就把图片文件关闭了,load()啥也获取不到。
5. 性能就很一般了,基本和初版差不多的速度。


五、终局之战

又经过一番研究和查证其实 Pillow verify()对渐进式图片检测是没问题的,误报率并没有我在V1测试时那么高,只是我本地环境的 Pillow 版本不够新而已,但也确实会有漏报。只用load()也会有漏报,有一点误报可以接受,但是漏报就无法接受了,所以还是需要联合检查。

最终决定采用如下逻辑
1. 先检测文件路径是否存在,收集所有路径。
2. img.verify()先上
3. 同一个循环内使用img.load()再来一次检测
4. 并行处理加快处理速度
5. 不在控制台显示扫描 log,毕竟绝大部分图片都是好的,没问题的显示出来无意义,只显示有问题的又很容易看起来像是卡住了,所以用 tqdm 做个进度条。还能大概估计下完成时间。
6. 用 jinja2 做个 html 格式的检测报告,毕竟在终端里复制粘贴起来也不方便。

代码V4.0(完善使用)

实在太长了就放github上了:img_validator.py

命令:python img_validator.py <"目录路径"> [并发数]

ex:python img_validator.py "D:\Download\图片" 8

最终会在脚本的同级目录下生成 html 格式的检测报告image_validation_report.html

  • 路径最好用””框住
  • 并发数可以不填,默认使用CPU全部线程。除非你用非常大的图,不然全线程跑也费不了多少CPU占用。
  • 理论上 10W 张图片在 12 线程下,用时应该半小时都不到,不过实际上受制于仓库盘使用的是 HDD 只能到 20~40files/s,机械硬盘的读出速度跟不上检测速度,特别是到最后20%的时候,速度更是掉到只有个位数了。18W 张图片的文件夹,检测用时接近5个小时,平均速度 ≈ 11 files/s
  • windows 和 unix 系统都可用,代码会自动处理两者的路径差异。

为什么会有这么多图片损坏

自己十年前写的P站抓取代码不完善,如果因为网络超时导致图片下载失败,爬虫会重试,但是之前损坏的图片有可能并不会被正确清除(删除部分代码没有正确处理超长文件名和带特殊符号的文件名),虽然带问题代码只使用了从14年到16年这大约一坤年,但是也积累了接近 600 张问题文件。不过倒是挺奇怪的,抓全年龄的部分出现大量这种问题,抓R18的几乎就没出错过,这是又为什么呢,沉思中…………

The post 如何快速批量检索损坏的图片文件—python开发学习笔记(一) appeared first on 秋风于渭水.