Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FileStorage's metadata doesn't match content #1268

Open
longfin opened this issue Aug 1, 2019 · 0 comments

Comments

@longfin
Copy link

commented Aug 1, 2019

In the uploaded database, tx/017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2 seems to has content (396 bytes).

> open debug.ldb
> fs.find tx/017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2
[1]: {"_id":"tx/017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2","filename":"017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2","mimeType":"application/octet-stream","length":{"$numberLong":"396"},"chunks":1,"uploadDate":{"$date":"2019-08-01T08:47:12.2220000Z"},"metadata":{}}

but after download as below, its content is empty.

> fs.download tx/017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2 017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2 
[1]: {"_id":"tx/017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2","filename":"017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2","mimeType":"application/octet-stream","length":{"$numberLong":"396"},"chunks":1,"uploadDate":{"$date":"2019-08-01T08:47:12.2220000Z"},"metadata":{}}
> exit
~/Downloads $ ls -al 017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2 
-rw-rw-rw-   1 Swen Mun       없음            0 2019-08-01 20:18 017c37b877e8d4806226efdcfb2d671d72cb893e54892bc2465f20ba89af82e2
dahlia added a commit to dahlia/libplanet that referenced this issue Aug 1, 2019
dahlia added a commit to dahlia/libplanet that referenced this issue Aug 2, 2019
Revert prev workaround for LiteDB and make it flush instead
It turns out that LiteDB's data corruption
(mbdavid/LiteDB#1268) seems to happen
due to sudden termination of program.  So the workaround made in the
previous patch (planetarium#386)
was reverted for the most part, and a new option named `flush` was
added to `LiteDBStore()` constructor.
dahlia added a commit to dahlia/libplanet that referenced this issue Aug 2, 2019
Revert prev workaround for LiteDB and make it flush instead
It turns out that LiteDB's data corruption
(mbdavid/LiteDB#1268) seems to happen
due to sudden termination of program.  So the workaround made in the
previous patch (planetarium#386)
was reverted for the most part, and a new option named `flush` was
added to `LiteDBStore()` constructor.
longfin added a commit to longfin/libplanet.net that referenced this issue Aug 6, 2019
longfin added a commit to longfin/libplanet.net that referenced this issue Aug 6, 2019
Revert prev workaround for LiteDB and make it flush instead
It turns out that LiteDB's data corruption
(mbdavid/LiteDB#1268) seems to happen
due to sudden termination of program.  So the workaround made in the
previous patch (planetarium#386)
was reverted for the most part, and a new option named `flush` was
added to `LiteDBStore()` constructor.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.