Closed max-moser closed 4 months ago
For us, the use case is that we have files on disk where the original filename has been "lost" from the FS perspective – they've been renamed to simply data
, and the original filename is only available from another source.
One way to go about this would be to create an appropriately named symlink to the actual file to analyze.
This can make the difference between correctly identifying a Python file vs. misidentifying it as Plain Text.
Thanks for this Max. I'm not sure why this symlink block was put in, perhaps to stop recursion into symlinked directories which might cause cycles?
Should be possible to add it.
A couple of questions:
I can see the threat of endless cycles with symlinked directories, that could quickly (or rather slowly) spoil somebody's day :sweat_smile:
Regarding your questions:
A feasible alternative in our case would actually be to honor the -name
option when reading a file from disk rather than from stdin – effectively telling siegfried that "the name on disk is wrong, here's the proper one"
More on the original rationale and potential to add symlink behavior back in: https://github.com/richardlehane/siegfried/issues/107#issuecomment-334128810
Hi Max, I've added a new -sym flag that you can use to follow symbolic links to files. To add it to your default configuration do sf -setconf -sym
. This will be available in next release, out in about a week. I've you'd like to test, there's a release candidate here: https://github.com/richardlehane/siegfried/releases/tag/v1.11.1-rc4
Awesome, thanks a lot!
Right now, siegfried refuses to scan symbolic links with an error message
file is of type symlink; only regular files can be scanned
:It would be nice to have an option (
-s/-follow-symlinks
?) that makes siegfried follow the symlink to the file to analyze.