Shared folders corrupting files

Discussions about using Linux guests in VirtualBox.
Post Reply
Munch
Posts: 2
Joined: 1. Sep 2022, 09:33

Shared folders corrupting files

Post by Munch »

I am also having an issue where shared folders corrupt the data that it writes.
Host Windows 10, Guest Linux Mint 21 Cinnamon. Latest VB Version 6.1.36 r152435 (Qt5.6.2) and guest additions.

I use qBittorrent and the download folder is my shared folder.
I have noticed that video files downloaded to a shared folder are corrupted and have glitches in when played. For months I blamed a bad source of the files, but I now investigated deeper and found it's the shared folders.

How I proved it's shared folders:
I took one of the corrupted files and readded the torrent in qBittorent such that it would seed the file as it believes it's downloaded 100%
I would take a sha256 hash of the file. Then I will instruct qBittorent to rescan the file and it would start the download at 99.6% again.
When complete I take another has and the hash is different.
Then I rescan again and again the download starts at 99.6% and again when 100% compare the hash. Again it's different from all previous hashes.
I can repeat this step over and over and the hashes change every time.

I then moved the same corrupt file to the linux guest machine and pointed the torrent to it. Rescan it starts at 99.6% and downloads to 100%. I perform a sha256 hash.
Rescan again and it says it's 100% already. I rehash and the hash stays the same. All glitches in the video file are now gone.

Note when I copy the file to the shared folder or from it that seems to work without corruption. It's only when the torrent downloads directly to the shared folder when this happens.
Note I have been download directly to the shared folder like this for years now without issues. It's only recently when this issue started. I regularly update VB and the guest additions.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Shared folders corrupting files

Post by mpack »

It has long been known that you shouldn't use shared folders actively, i.e. having guest software hold files open for extended periods of time. They are used as an intermediate medium for copying files between guest and host. Basically the host writes, the guest reads.

If you want to make more extensive used of a shared folder, set up a true network share.
arQon
Posts: 228
Joined: 1. Jan 2017, 09:16
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Ubuntu 16.04 x64, W7

Re: Shared folders corrupting files

Post by arQon »

mpack wrote:It has long been known that you shouldn't use shared folders actively, i.e. having guest software hold files open for extended periods of time.
hmm...

I haven't downloaded anything NOT to a shared folder in, hmm, probably a little over a decade, give or take. The overwhelming majority of those downloads are of archives: zip originally, 7z more recently - both of which have CRCs to validate their integrity with, and obviously none have ever been corrupted in this way or I wouldn't be making this post. :)
I do clean up old files there every once in a while, but it's got over 450K files and 275GB in it. That's a huge amount of evidence in opposition to put an unsupported claim of unreliability up against, no matter who's making it.

So the real question is, assuming we trust the premise at all, what do we think counts as an "extended period of time"?

I do torrent new Ubuntu versions every 6 months, but it turns out those actually go to the NAS. I seem to only have ever once run one through a shared folder instead, back in 2019. Certainly not a large enough sample size to be able to argue that "torrents in general" are fine, but also certainly enough to show that even a 2GB torrent (eesh, Ubuntu was a LOT slimmer back then!) is not guaranteed to fail in strange and subtle ways. I have no idea how long it took, but it can't have been less than 15-20 minutes back then, and probably around twice that. That's a *very* long time from a software perspective though: off the top of my head I can't think of anything other than a log file that would ever be held open that long by anything, and I can easily see it being missed by even reasonable testing. I don't think the claim is incredible, but there's clearly a lot more to it than a one-sentence summary can say.

Obviously nobody knows what the problem *is*, or it would be fixed by now, but we can probably make some guesses and potentially refine them as information comes in. > 24 hours? Across a date change? Does anyone have any support for OP's experience and/or mpack's position?
Post Reply