steffenfritz / filedriller Goto Github PK

Describe the bug
Directorynames/paths get splitted up in several csv-fields, when they contain a comma.
E.g.: "OCRA, OCRB, MICR"

To Reproduce
Steps to reproduce the behavior:

1. Let filedriller analyze a folderstructure containing such a name
2. the output csv will contain a line/lies with cutted directorynames and too many data fields

Expected behavior
the csv should be written in a correct way.
E.g. by using "" around the filename

Can we have a column for the basic file type in analogy to the "find" command? ("f" for files, "d" for directories etc.)

(Copy of codeberg.org issue nr. 5)

Hi Steffen,

when experimenting with problematic hd-images containing identical files at several distinct paths - which I can easily detect already by sorting by hash-value, what is great already (!) - I thought that as an additional output-option the mtime of the files would be great.
We then could easily detect the oldest copy of identical files, and only treat that specific copy.

What do you think, could you implement mtime in a next version?

Many thanks and BR,
Stephan

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Filedriller uses one hash function per run, i.e. sha1 XOR sha2 XOR ...

It would be useful if Filedriller could create more than one hash function per run, i.e. sha1 AND SHA2 AND ...

Describe alternatives you've considered
None.

Additional context
None.

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Filedriller should have a GUI. All cli flags should be accessible via the GUI.

Describe alternatives you've considered
None.

Additional context
None.

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Filedriller should log processing information about each run to a file. This includes at least:

1. Version of Filedriller
2. Version of the signature file used in the run
3. Version of siegfried
4. Timestamps: start, end
5. Platform, i.e. operating system and version
6. warnings and errors
7. File count, i.e. found vs processed

Describe alternatives you've considered
None.

Additional context
None.

Describe the solution you'd like

• input directory or file should be logged to logfile
• device should be logged to logfile
• filesystem info should be logged to logfile

Describe the solution you'd like
Go 1.16 introduces the embed package and a directive for embedding files into a program during compilation.

What would be the benefit of the change?

• Signature file and filedriller version are coupled
• No side effects
• No new signature format can break filedriller

Please provide a use case if possible
n/a

Describe alternatives you've considered
n/a

Additional context
https://tip.golang.org/doc/go1.16#library-embed

Describe the solution you'd like
Add an arbitrary comment string to the log file via flag.

What would be the benefit of the change?
Add more information to the run.

Please provide a use case if possible
Add user name
Add usage notes
...

Describe alternatives you've considered
Write a bagit-like information file

Currently empty directories are not processed or documented at all, if I'm not mistaken.

Friller should process empty directories, assign a UUID to them and document all available technical metadata.

A column in the output file for the (relative) hierarchy level of each file/directory recorded seems useful.

Describe the solution you'd like
filedriller should be configurable via a configuration file.

What would be the benefit of the change?
A more convenient way to start repetitive scans.

Describe the solution you'd like
There should be the possibility to write output to a database, not just a file.

What would be the benefit of the change?
Partial runs and it builds the foundation for more file type dependent analyzing operations.

Describe the bug
friller fails to process about 50% of the files in an test-case (extracted MacOS files).
For the failed files, no Hash, no Dates and no inNSRL is generated.

Screenshots

friller.log
INFO: 2023/01/05 12:41:56 friller started
INFO: 2023/01/05 12:41:56 Platform: windows on amd64
INFO: 2023/01/05 12:41:56 Friller Version: 1.0.0-BETA-8
INFO: 2023/01/05 12:41:56 Friller Build: b310253
INFO: 2023/01/05 12:41:56 Siegfried signature file: pronom:DROID_SignatureFile_V109.xml;container-signature-20221102.xml
INFO: 2023/01/05 12:41:56 Input path: D:\Disks\00_Extractions\frill_test/
INFO: 2023/01/05 12:41:56 Hash algorithm used: sha1
INFO: 2023/01/05 12:41:56 Comment:
INFO: 2023/01/05 12:41:56 NSRL lookup enabled: true
INFO: 2023/01/05 12:41:56 Entropy calculation enabled: false
INFO: 2023/01/05 12:41:56 Inspecting 1308 files
INFO: 2023/01/05 12:42:18 Inspected 1308 files.
INFO: 2023/01/05 12:42:18 Output written to C:\Temp\frill.csv
INFO: 2023/01/05 12:42:18 friller stopped

Additional context
see attached error.log
friller_err.log

For a appropriate, complete file listing the output should contain columns for

• Permissions
• UserID
• GroupID
• ModDate
• ModTime
• StatusChgDate
• StatusChgTime
• AccessDate
• AccessTime

(copy of codeberg.org issue nr. 4)

Hi Steffen,

as promised some weeks ago in Marbach :-)

For files bigger than 1GB, one could use just a 1GB part of the file (this should be representative enough, I guess?).
E.g.: just read the first 1GB, and calculate the entropy of it.

BR,
Stephan

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
Filedriller should accept single files as input, not just directories. This would allow to combine Filedriller with other tools on the command line, i.e. piping.

Describe alternatives you've considered
None.

Additional context
None.

Describe the solution you'd like
It would be helpful to have a progress bar

What would be the benefit of the change?

1. See, if filedriller is still working and to estimate the remaining work time