unknown files "xyz.db"

roluan17 · 2023-04-24 08:08:27

Lokking for big files on my system:
4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux

I found 5 files, each 4 GB, named like "xyz.db" in a directory named "recover".

Has anyone an idea where this might come from? Can't remember that I did that (so not a 100% proof)
;-)

Anyway 20 GB is a lot of wood, just delete them, seems a bit risky to me.

Any hints?
Thanks

xinomilo · 2023-04-24 10:00:52

what does `file xyz.db` say?
creation date?

could be a db backup, or something else. do you have a database server running on that system?

roluan17 · 2023-04-24 14:22:02

>what does `file xyz.db` say? creation date?

-rw-r--r-- 1 root root 4294967295 Jul 6 2020
(Can't remember what I could have done three years ago to create them)

>could be a db backup, or something else. do you have a database server running on that system?

No, just a normal pc, no database server (as far as I know)
[UPDATE] I tried to open one of the files using sqlite3. But no hint about the content, only a long row of
-- unrecognized token " "
-- syntax error
-- and unreadable characters
runs about 15 minutes

LibreOffice doesn't know to open it (or better said I don't know how to make LibreOffice open it)

boughtonp · 2023-04-24 16:21:34

roluan17 wrote:

>what does `file xyz.db` say? creation date?
-rw-r--r-- 1 root root 4294967295 Jul 6 2020

Entering file xyz.db will not give that output!

It looks like ls -l output (with filename removed), and ls doesn't give a file's creation date - it gives mtime (modification) but can be requested to give atime (access) or ctime (file status change).

Running stat xyz.db will give all three times precisely - along with a value for file creation called "birth" if the filesystem supports it - likely mtime and ctime are the same, but if they differ then this may indicate if/when the file was copied to that system from elsewhere.

Camtaf · 2023-04-24 17:01:12

roluan17 wrote:

>what does `file xyz.db` say? creation date?
-rw-r--r-- 1 root root 4294967295 Jul 6 2020
(Can't remember what I could have done three years ago to create them)

If they've not been used in nearly 3 years, I'd just delete them - or copy/move them to external media, if you are unsure.

roluan17 · 2023-04-24 19:19:45

Sorry! Misinterpreted "file" ...

"file xyz.db" results in:
"Composite Document File V2 Document, Cannot read section info"

"stat xyz" gives:
file: xyz.db
size: 4294967295 blocks: 8388616 EA block: 4096 regular file
Device: 808h/2056d Inode: 5510191 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access : 2023-04-24 19:47:44.524001543 +0200
Modify: 2020-07-06 17:26:34.000000000 +0200
Change: 2021-03-04 22:45:42.316023800 +0100
Birth : -

boughtonp · 2023-04-24 20:57:35

Well there we go - there's a March 2021 date in addition to the July 2020 date - maybe that sheds more light.

Otherwise, putting "Composite Document File V2 Document" into a search engine reveals:

https://en.wikipedia.org/wiki/Compound_File_Binary_Format wrote:

Compound File Binary Format (CFBF), also called Compound File, Compound Document format,[1] or Composite Document File V2[2] (CDF), is a compound document file format for storing numerous files and streams within a single file on a disk. CFBF is developed by Microsoft and is an implementation of Microsoft COM Structured Storage.[3][4][5]
Microsoft has opened the format for use by others and it is now used in a variety of programs...

So it's Microsoft's version of a TAR file, and could potentially contain anything.

Briefly looking at other results suggest it may be meaningful data but might also just be a temp file.

roluan17 · 2023-04-25 08:14:22

Sorry again! You are right, I could have done that myself.
What I then found out further is that Billy Boy offers a free (?) program: "Visual Studio 2022" to open it.
Any other idea than going to a neighbour and looking it up on his machine?

Are there other possibilities within Linux?
Sqlite3 just give cryptic characters ... as i mentioned above.

It might be that these are useless temp files, right.
But as it is named "recover" (i myself would not name a recover file "recover" but Sicherung or something like that) I suspect it might be something I should store.
It could be something from the time I ran "teams" on my machine for my sons home schooling period during corona-times.
("teams" did a lot of uncontrollable things and was not -as promised- running within Firefox alone, crashed several times and was then removed, last time I ran one of Billy's products)
Thanks

fsmithred · 2023-04-25 12:20:21

At first I was thinking maybe you could see the contents of the file with zless or hexedit, but a little searching reveals that it contains a FAT filesystem. In that case, you might be able to mount it. Try fdisk -l xyz.db to figure out what the offset is. (sector size X start sector)

Maybe...
mount -o loop,offset=$OFFSET xyz.db /mnt

roluan17 · 2023-04-25 13:15:50

"fdisk -l xyz.db " gives:

xyz.db: 4 GiB, 4294966784 bytes, 8388607 sectors

sudo mount -o loop,offset=$OFFSET xyz.db /mnt
mount: bad usage
Try 'mount --help' for more information.

#Request patience

boughtonp · 2023-04-25 13:36:13

Visual Studio is a development environment (IDE) - wouldn't surprise me if it can open it, but hopefully there will be simpler options.

It might be that, either instead or in addition to mounting it as fsmithred suggests, you need one of the tools listed here:
https://en.wikipedia.org/wiki/COM_Struc … mentations

Seems plausible that it's relating to Microsoft Teams crashing and writing everything in memory to disk, or something like that.

Another thing you could look for is if there are other files on disk with similar modification times. (Or if you still have any log files from back then, grep those to see if there's any relevant messages.)

For example, find can identify files modified within 5 minutes either side, like so:

find START_PATH -newermt '2020-07-06 17:21' -not -newermt '2020-07-06 17:31'

Replace START_PATH with a suitable directory, e.g. /home/user and maybe also try with switching -newermt to -newerct (or -newerat), as per -newerXY in find docs.

fsmithred · 2023-04-25 15:51:06

sudo mount -o loop,offset=$OFFSET xyz.db /mnt

FYI, you need to replace $OFFSET with a number, but I don't see the numbers you need from the fdisk command to calculate the offset. (sector size X first sector)

The officially official Devuan Forum!

#1 2023-04-24 08:08:27

unknown files "xyz.db"

#2 2023-04-24 10:00:52

Re: unknown files "xyz.db"

#3 2023-04-24 14:22:02

Re: unknown files "xyz.db"

#4 2023-04-24 16:21:34

Re: unknown files "xyz.db"

#5 2023-04-24 17:01:12

Re: unknown files "xyz.db"

#6 2023-04-24 19:19:45

Re: unknown files "xyz.db"

#7 2023-04-24 20:57:35

Re: unknown files "xyz.db"

#8 2023-04-25 08:14:22

Re: unknown files "xyz.db"

#9 2023-04-25 12:20:21

Re: unknown files "xyz.db"

#10 2023-04-25 13:15:50

Re: unknown files "xyz.db"

#11 2023-04-25 13:36:13

Re: unknown files "xyz.db"

#12 2023-04-25 15:51:06

Re: unknown files "xyz.db"

Board footer