September 6th, 2020, 2:46
September 6th, 2020, 12:13
September 6th, 2020, 14:27
f2175681376.mpg 0-1073565695 = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_1.VOB
1073565696-1073741823 = fragment of another movie, probably deleted
1073741824-1140850687 (end of file) = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_2.VOB 0-67108863
f2178168944.mpg 0-1433599 = fragment of another movie, probably deleted
1433600-1007890431 = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_2.VOB 67108864-1073565695
1007890432-1008066559 = too short, unidentified
1008066560-2014699519 (end of file) = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_3.VOB 0-1006632959
f2182356824.mpg 0-4722687 = too short, unidentified
4722688-71655423 = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_3.VOB 1006632960-1073565695
71655424-71831551 = unidentified
71831552-1145397247 = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_4.VOB 0-1073565695
1145397248-1145573375 = unidentified
1145573376-2017988607 (end of file) = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_5.VOB 0-872415231
f2186554552.mpg 0-2969599 = unidentified
2969600-204120063 = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_5.VOB 872415232-1073565695
204120064-204296191 = unidentified
204296192-1277861887 = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_6.VOB
1277861888-1278038015 = unidentified
1278038016-2016235519 (end of file) = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_7.VOB 0-738197503
f2190754504.mpg 0-77823 = unidentified
77824-335446015 = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_7.VOB 738197504-1073565695
335446016-335622143 = unidentified
335622144-808830975 (end of file) = DANSE_AVEC_LOUPS\VIDEO_TS\VTS_01_8.VOB
September 6th, 2020, 14:41
Drive was re-formatted. Was originally formatted in Ext4 (in some kind of NAS). But how would it be relevant now ?
I did this recovery some months ago, the original drive has been repurposed since then, so all I have is the recovery
The method I'm looking for would be useful in all situations where both a filesystem based recovery and a “raw” recovery are performed on the same storage device.
In this particular case, one file recovered by Photorec contains data belonging to several distinct original files
September 6th, 2020, 15:45
You mean you don't have disk image?
In general if file system scan delivers good results, don't bother with RAW results.
I think this is default behavior in ReclaiMe and probably other tools as well. If file is detected using both meta data and RAW scan, file is removed from RAW scan.
September 7th, 2020, 7:42
$offset = 1024
$length = 16
foreach ($file in gci *.mpg, *.vob, *.mts) {
$buffer = [Byte[]]::new($length)
$stream = [System.IO.FileStream]::new($file.FullName, 'Open', 'Read')
$stream.Position = $offset
$readSize = $stream.Read($buffer, 0, $length)
$stream.Dispose()
if ($readSize) {
$ascii = [System.Text.Encoding]::Default.GetString($buffer)
$name = $file.FullName
$size = $file.Length
Add-Content -Path "G:\HGST 4To MPG-VOB-MTS logical search -- 1024 16.txt" -Value "$ascii $name $size"
}
}
$buffer = $null
$Encoding = [Text.Encoding]::GetEncoding(28591)
$StreamReader = New-Object IO.StreamReader -ArgumentList $buffer, $Encoding => fails, this command apparently expects a path and won't accept the previously defined variable $buffer
dsfo "G:\dummy file.ext" 1024 32 $
H:\>dsfo "G:\Cover 20200905.png" 1024 32 $
OK, 32 bytes, 0.000s, MD5 = 47a6148e5e71d111a231b4e1322ae5f9
September 8th, 2020, 15:17
September 21st, 2020, 16:18
You did a mess between normal recovery and RAW and want to dig into it.
Step back and do it properly.
1) Scan and find all structured data, map it.
2) Make RAW scan only unmapped area to avoid dublications.
September 22nd, 2020, 3:09
September 24th, 2021, 14:33
Powered by phpBB © phpBB Group.