Skip to content

Conversation

@Burgos
Copy link

@Burgos Burgos commented Aug 25, 2018

On filesystems where hardlinking is not supported, freight-cache will
failback to copy to add packages into the pool, which will support
serving repositories from these filesystems (such as cloud storage
mounted with fuse).

@Burgos Burgos force-pushed the noln branch 2 times, most recently from cc69207 to 94e091b Compare August 25, 2018 19:05
On filesystems where hardlinking is not supported, freight-cache will
failback to copy to add packages into the pool, which will support
serving repositories from these filesystems (such as cloud storage
mounted with fuse).
@Burgos
Copy link
Author

Burgos commented Aug 30, 2018

Turns out this doesn't work good with purging the cache's pool. I'll investigate if it can be improved.

@minecraftchest1
Copy link

What about symlinks?

@skybert
Copy link

skybert commented Jan 10, 2024

Turns out this doesn't work good with purging the cache's pool. I'll investigate if it can be improved.

Yes, I was bitten by this one yesterday. In my case, it was if the target file is read only, freight will fall back to cp (with this PR). This means the link count isn't increased, on which the logic in apt_clean() relies, causing it to remove the DEB in the cache pool. apt-cache would find the package since the Packages was correct, but apt-get would fail to install it. Because errors from ln were redirected to /dev/null, it was rather tricky to figure out.

What about symlinks?

That doesn't update the link count, which breaks apt_clean()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants