Two sessions writing to the same potfile

[devilsadvocate]

Can 2 separate hashcat sessions write to the same potfile?

Or will that cause a tear in the fabric of the space time continuum?

In Linux, this may come down to how 2 separate processes handle appending data to the same file.  With databases, "locks" can occur on objects while they are being written to.  Is there a Linux OS equivalent?  Would there be a "lock" on the file when one process is appending to the potfile so that the other process has to wait before it can also append?

I found a few references.
https://gavv.github.io/blog/file-locks/
https://www.thegeekstuff.com/2012/04/lin...ing-types/
https://en.wikipedia.org/wiki/File_locking

[CUwindows00]

sorry

[CUwindows00]

sorry

[devilsadvocate]

Hello everyone

Ask a question of hashcat rules
Why do not many combination rules have such a rule?

Swap location attack rule
For example:

cat 1.txt 
abc

cat 2.txt
123

cat 3.txt
!@#$

I think this rule is advanced and effective.

Hashcat does not have such a rule

The 3 combination attack rule generation should be the result of the following dictionary

abcabcabc
abcabc123
abcabc!@#$
abc123abc
abc123123
abc123!@#$
abc!@#$abc
abc!@#$123
abc!@#$!@#$
123abcabc
123abc123
123abc!@#$
123123abc
123123123
123123!@#$
123!@#$abc
123!@#$123
123!@#$!@#$
!@#$abcabc
!@#$abc123
!@#$abc!@#$
!@#$123abc
!@#$123123
!@#$123!@#$
!@#$!@#$abc
!@#$!@#$123
!@#$!@#$!@#$

Maybe you should consider starting your own thread instead of randomly posting on this one.

I'm pretty sure this has nothing to do with file locks.

[CUwindows00]

sorry

[GOD]

Can 2 separate hashcat sessions write to the same potfile?

Of course they can... Unless you specify the option to disable potfile within one of the sessions. I'm sure you could have just easily tested this on your own.

Also, trying to edit the potfile and save it will fall into what you're referring to, therefore throwing an error of "file is in use by another process."

[royce]

Use the source, Luke.

If you look at locking.c and potfile.c in the source code, it appears that (as long as you're not on Windows), some basic locking of the potfile is happening.

That being said, I suspect that using -o/--outfile combined --remove would probably be more easily controlled.