Files set to 2008, 1998, 2080, 2041

>Is that a MicroSD card? My friend bought a fake MicroSD on eBay (he obviously didn't know until it corrupted itself) and this exact thing happened after a couple of months of use.
or maybe its just that i mean i its a real usb so i ddont know

I have no idea.
Spotted your /x/ thread.

Unplug the USB for now, you're just doing damage to it.

Get linux and try to make a bit for bit copy of the USB to work with on anything you have handy.

1. what kind of storage device is it?
2. what brand?
3. how old is it?
4. are the files still on it?
5. did they work?
6. what where you doing when this happened?
7. when was the last time you used it?
8. did you plug the device into a different port this time than the last time that it worked? or is the device plugged into a different computer?

also install malwarebytes and do a virus scan. you might have an encryptor.

What the fuck is this

Attached: 557.jpg (680x793, 38K)

>horny as fuck
>download like 500 jav from fapnyasi
>auto extract files all files in one folder
>theres like thousand of files like op pic

No he just got wacked by a bitshift on NTFS or something.

The solution is to repartition your drive EXT4 and install linux.

>NTFS

Attached: 1512841135927.jpg (200x200, 23K)

I know that feel, same happened with some MMD 18+ vids I tried downloading a few years ago.
I eventually settled on a large hentai pack and some nice MUM JAVs.

Install Gentoo and it'll work again.

Attached: Screenshot_2018-07-25_00-23-06.png (320x281, 70K)

This is what happens when you don't properly eject/umount a USB stick before removing it.

touch *

Probably not entirely.
Most likely had a bitshift or CRC error in the MFT of the USB that shredded everything on it -as- it was ejected in a dirty state.

Attached: 1527887470932.jpg (1683x1080, 462K)

ah! good Ol' NTFS. You deserve it winfag.

Except it obviously isn't NTFS - which even an amateur could figure out looking at that directory listing.

Attached: 1514899233402.jpg (512x446, 37K)

BUT I NEED TO FIT IN WITH THE COOL KIDS

Trying to cover up your time traveling ways I see

>those boomers who can't get their head around filesystems
Surely you mean file allocation table, that's what FAT stands for and NTFS still uses.

filesystem corruption, format and restore backup
and next time remember to safely remove, it's there for a reason

FAT uses File Allocation Table
NTFS uses Master File Table

Attached: a.png (624x445, 39K)

i dont fucking now

Can't you just enable synchronous writes and be safe? So long as you're not ripping it out DURING a write operation.

Attached: Untitled.png (400x455, 12K)

i'm almost certain they made that the default because too many people just pulled things out and complained when things got corrupted
it also hurts performance, it's better overall to have it in async and use safe remove

I'm inclined to agree, however I personally stick with the default for the OS, but use a separate tool that does it's own type of caching when I want speedier writes.

Attached: fast-copy.png (737x703, 55K)

even i find it hard to give up convenience, most people will pick convenience over basically anything else (i should not have to give any examples)
but even with sync writes, you can still get unlucky
most flash drives have an access light on them, which you can use to gauge inactivity, but a write can begin way faster than the time between committing to remove the device, and actually removing the device, that is, it can start a write right as you're removing it
this can't happen if you safe remove/unmount beforehand, you have that safety and peace of mind knowing that the filesystem is clean
i've run into filesystem corruption too many times for me to fuck with luck like that

-- basically, data is more important than convenience
i'd rather be paranoid about syncing devices before removal than curse over lost data

Have people not come up with something better by now? It's hard for me to imagine that we don't have a more resilient (without compromise) filesystem. Corrupting/negating the record you were trying to store sounds fair enough to me, corrupting the entire filesystem as a whole for a write on even a single record, is too much imo.

Same, for me, this extends to things like redundant drive arrays, etc.

>Have people not come up with something better by now?
yea, data journaling and copy-on-write
neither of which ntfs or fat do. (ntfs has metadata journaling, but that's it, you can still corrupt data with a short write)

which basically mean;
journaling: write to a journal, then commit that change to the filesystem once it's done, an interrupted write will trigger a journal replay upon the next mount, and the fs driver can sort out what's good and clean things up
copy-on-write: instead of directly overwriting changes, you write to an unused portion of the disk, then change the metadata to point to the new location once it's done. an interrupted write just means you get the old data instead

keep in mind these shouldn't be relied on, they prevent filesystem corruption, but not application-level corruption
as an example, lets say you're updating a game, and it's half way done, if you interrupt it, all the filesystem can do is ensure writes before the removal are good, but the game is still only partly updated, so while individually the files may be ok, as a whole they're in a weird state, and the game itself will probably be broken

It's a message from the future. You have to go back to 1975 and acquire an IBM 5100.

Attached: 1526580862849.jpg (960x619, 165K)