Skip to content

Conversation

@aslilac
Copy link

@aslilac aslilac commented Apr 3, 2025

Closes #486

Currently, every call to Open "copies" the File, but since it has pointer fields, it's not really the kind of clean independent copy that's desired here. Notably, every File shares the same bytes.Reader state.

This causes a few bugs:

  • A file which has been read to the end will be unreadable by anyone else.
  • Any file which has been Closed has had data set to nil, essentially permanently erasing that file.

My proposed solution is to introduce an internal fsEntry type, and to construct a new tarfs.File from that data on each call to Open. Continuing to share a *tar.Header field seems fine, as you shouldn't modify that during normal use.

@CLAassistant
Copy link

CLAassistant commented Apr 3, 2025

CLA assistant check
All committers have signed the CLA.

@aslilac aslilac changed the title construct a new bytes.Reader per each opened file construct a new bytes.Reader per each opened file in tarfs Apr 3, 2025
@Emyrk
Copy link

Emyrk commented Apr 22, 2025

@sagikazarmark are PRs being actively reviewed?

@sagikazarmark
Copy link
Collaborator

Makes sense to me. Added to my review queue.

@dannykopping
Copy link

@sagikazarmark following up on this one; do you intend to review/merge it any time soon?

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.

tarfs.FS uses shared file position for each file handler

5 participants