Write symbolic links to disk #362
Comments
|
|
|
Hi @csisl! I'd love to help, but could use some additional info.
OFRAK is definitely supposed to handle symbolic links, so I want to make sure we address this, but I'm having trouble replicating this locally. I made the following test file using these commands on Debian: csisl-test.tar.gz mkdir -p /tmp/test
cd /tmp/test/
echo "Hello, world!" > hello.txt
touch empty.txt
ln -s hello.txt link.txt
ln -s self-link.txt self-link.txt
ln -s link.txt second-link.txt
ln -s nonexist.txt dead.txt
cd ..
tar -czvf csisl-test.tar.gz test/When I unpack in the OFRAK GUI, it looks like this. The 
Modifying "world" in You can test the process yourself by running this script generated by the GUI. from ofrak import *
from ofrak.core import *
async def main(ofrak_context: OFRAKContext, root_resource: Optional[Resource] = None):
if root_resource is None:
root_resource = await ofrak_context.create_root_resource_from_file(
"csisl-test.tar.gz"
)
await root_resource.unpack()
genericbinary_0x0 = await root_resource.get_only_child(
r_filter=ResourceFilter(
tags={GenericBinary},
attribute_filters=[
ResourceAttributeValueFilter(attribute=Data.Offset, value=0)
],
)
)
await genericbinary_0x0.unpack()
folder_test = await genericbinary_0x0.get_only_child(
r_filter=ResourceFilter(
tags={Folder},
attribute_filters=[
ResourceAttributeValueFilter(
attribute=AttributesType[FilesystemEntry].Name, value="test"
)
],
)
)
file_hello_txt = await folder_test.get_only_child(
r_filter=ResourceFilter(
tags={File},
attribute_filters=[
ResourceAttributeValueFilter(
attribute=AttributesType[FilesystemEntry].Name, value="hello.txt"
)
],
)
)
config = StringFindReplaceConfig(
to_find="world",
replace_with="GitHub",
null_terminate=False,
allow_overflow=True,
)
await file_hello_txt.run(StringFindReplaceModifier, config)
await root_resource.pack_recursively()
await root_resource.flush_to_disk("csisl-test-2.tar.gz")
if __name__ == "__main__":
ofrak = OFRAK()
ofrak.run(main)Unpacking that repacked file again in OFRAK shows that the symbolic links are still there, so OFRAK can (at least in this case) handle unpacking and repacking symbolic links. 
I also tried the following small script to flush a symbolic link to disk. from ofrak import *
from ofrak.core import *
async def main(ofrak_context: OFRAKContext):
root = await ofrak_context.create_root_resource_from_file("csisl-test.tar.gz")
await root.unpack()
tar = await root.get_only_child()
await tar.unpack()
folder_test = await tar.get_only_child()
# Shows symbolic link children
print(list(await folder_test.get_children()))
file_dead_txt = await folder_test.get_only_child(
r_filter=ResourceFilter(
tags={FilesystemEntry},
attribute_filters=[
ResourceAttributeValueFilter(
attribute=AttributesType[FilesystemEntry].Name, value="dead.txt"
)
],
)
)
# Successfully writes, but writes an empty file
await file_dead_txt.flush_to_disk("test_dead.txt")
o = OFRAK()
o.run(main)This script runs without issue and creates |
|
Based on my current understanding of the issue you're reporting (that Does that fix the issue you are describing? I still can't replicate |
|
Hello! Thank you for the response. As for my environment, I am running with the following setup:
I followed the steps above that you used to create a directory with one text file and then several symbolic links. Whenever I do this and run ofrak on the command line, the only file that is preserved is the A file listing: This is the behavior I'm seeing whenever I run As for the While I can see the symbolic links in the GUI
I cannot see the symbolic links that point to files whenever I iterate over the children:
What's interesting is I haven't tried with a dead link until following your instructions above. As of now, it is only recognizing the dead link, not the ones that point to the file |
|
Currently, we've merged #373, so it should be possible to dump symbolic links via the following (assuming you've installed OFRAK from the if resource.has_tag(FilesystemEntry):
entry = await resource.view_as(FilesystemEntry)
await entry.flush_to_disk()Working on a separate PR to make the |
|
@rbs-jacob, can this issue be closed? |
What is the use case for the feature?
Whenever a symbolic link is encountered, it is not written to disk because it is considered an empty file. This can lead to false negatives of a file being found when unpacking and also does not maintain the integrity of the original compressed package. The user should have the ability to resolve and follow the symbolic link as seen fit
Does the feature contain any proprietary information about another company's intellectual property?
No
How would you implement this feature?
Whenever writing files to disk, if an empty file is encountered, first check to see if it's a symbolic link. If it is, write the link to disk
Are there any (reasonable) alternative approaches?
Are you interested in implementing it yourself?
The text was updated successfully, but these errors were encountered: