Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #6: check path matches, rather than blindly selecting metadata #7

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

joshbarrass
Copy link

@joshbarrass joshbarrass commented Apr 26, 2023

Fixes #6 by checking the path within each entry with a matching checksum to ensure it matches the path of the file we're currently opening. Tested and confirmed working on Linux, and should work on any Posix system. Needs testing on Windows.

More Detailed Explanation

Previously, it was assumed in freezefs that the first freezetag entry with a matching checksum corresponded to the correct metadata. However, this is not a valid assumption, and this edge case is correctly handled by the thaw command but not by the mount command. To rectify this, the target_path is generated from the path stored in the frozen_entry, which is of the form /freezetag_root/path/to/file.ext. Correct me if this assumption is wrong, but from my testing it seems that any file referenced by a freezetag file, regardless of where it is stored on the real filesystem or where it is stored relative to the freezetag file, is added to the freezefs at its relative path from the root directory stored in the freezetag file (though one possible edge case I can think of is a freezetag file where the root is /). The first two components of this path, / and freezetag_root are removed, and the remaining parts, path, to and file.ext are joined into path/to/file.ext. This matches the form of the path in each entry of freezetag.data.frozen.files, so we can compare the two paths whenever the checksum matches to ensure we are selecting the correct metadata.

This solution will need testing on Windows, as I am not sure whether joining the parts of the path using the / character is appropriate. I am not sure exactly how the freezetag.data.frozen.files paths are represented on a Windows system. It may be necessary to join the paths using os.path.sep instead. Unfortunately, I do not have a Windows computer to hand with the correct environment to test this myself, so if someone else could test this, that would be great.

@joshbarrass
Copy link
Author

In my tests, I have tested:

  • a FLAC file in the freezetag root
  • a FLAC file in a subdirectory of the freezetag root

If there are any other test cases that would be worth looking at, let me know and I will try them.

powerarmorpatch pushed a commit to powerarmorpatch/freezetag that referenced this pull request May 26, 2023
… audio data

Author: joshbarrass
x1ppy#7

reezetag seems to support tracks with identical audio but different metadata when
thawing (each checksum is mapped to an array of files, and will then restore the
correct metadata for each). However, when using the mount command, only the one
file is restored properly; all subsequent files will be given this file's metadata.
@undaunt
Copy link

undaunt commented Oct 1, 2024

@joshbarrass Added this to my fork.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants