/wsr/ - Worksafe Requests » Thread #874045

[63 / 11 / ?]

5KiB, 111x128, 1597663320145.png

Locked files

Anonymous Mon 17 Aug 2020 16:22:04 No.874045 View View Reply Original Report

Quoted By: >>874050 >>874079 >>874131 >>874173

I tried out Linux the other day and while I was in the distro (Mint) I wrote and read some stuff from an external HDD.

When I access that HDD in Windows 10, all the files in the folder I accessed have a yellow lock on them and are unreadable.

Google told me to reset permission which I did but it didn't fix it.

Anonymous

Anonymous Mon 17 Aug 2020 16:32:01 No.874050 Report

Quoted By: >>874051 >>874052

>>874045

Ah, Windows and its stupid ownership mechanic, a concept which Linux has of course as well (rwx) but on Windows it is LEGENDARY annoying to get back.
You will have to take back ownership of the files, which means fiddling around in the Security tab which can mean up to having to TYPE MANUALLY IN the ID of the desired owner.
Fun.

Anonymous

Anonymous Mon 17 Aug 2020 16:37:42 No.874051 Report

Quoted By: >>874058

>>874050
>TYPE MANUALLY IN the ID of the desired owner.
What are you smoking? The default user to take ownership is you, so you just have to be you.

Anonymous

View Same Google ImgOps iqdb SauceNAO dgfhsdfgh.jpg, 137KiB, 484x556

Anonymous Mon 17 Aug 2020 16:39:27 No.874052 Report

Quoted By: >>874062

>>874050
>I did but it didn't fix it.

Anonymous

Anonymous Mon 17 Aug 2020 16:49:40 No.874058 Report

Quoted By: >>874061 >>874073

>>874051

Sometimes that isn't enough, especially when trying to access files on another Windows system. I had that when installing my old HDD with its old Windows system in my new one. Changing the owner to Users or me in the menu did not work, I had to use Add and add the full ID of my account EVEN THOUGH IT WAS LITERALLY THE ONE USING AT THAT MOMENT, add THAT one to the list and give it all permissions and only THEN it would be so benign to allow me accessing the files...
Then I switched to Linux which simply doesn't give a fuck about Windows permissions at all.

Anonymous

Anonymous Mon 17 Aug 2020 16:53:20 No.874061 Report

Quoted By:

>>874058
> it would be so benign to allow me accessing the files
You're saying the OS should just magically know that a user that ISN'T you IS you? How do you propose that would work?

Anonymous

View Same Google ImgOps iqdb SauceNAO change-owner-advanced[1].jpg, 66KiB, 767x520

Anonymous Mon 17 Aug 2020 16:54:47 No.874062 Report

Quoted By: >>874075 >>874076

>>874052
No, take ownership of it. Pic related.

Anonymous

View Same Google ImgOps iqdb SauceNAO no you didn't.png, 23KiB, 515x579

Anonymous Mon 17 Aug 2020 17:04:22 No.874073 Report

Quoted By: >>874157

>>874058
>I had to use Add and add the full ID of my account EVEN THOUGH IT WAS LITERALLY THE ONE USING AT THAT MOMENT, add THAT one to the list
There's so much wrong here I don't know where to begin.

>I had to use Add and add the full ID of my account
No you didn't, you can just enter your username and press "check names", or if that's too much typing go advanced-->find now, then click from a list of all the objects. Pic related.

>add THAT one to the list
Obviously your file was missing creator_owner, for reasons unknown. The correct solution is to take ownership and add creator_owner, not to add your specific UID. The correct correct solution is to take ownership of the top-level container everything's inheriting from (\users.old\your_username), and then all the inherited permissions will just work for literally everything inside the container and job done.

The main thing is that you could have spent twenty minutes actually learning how NT ACLs work, rather than hours trying to make them work the way you want them to work.

Anonymous

Anonymous Mon 17 Aug 2020 17:05:29 No.874075 Report

Quoted By: >>874076

>>874062
Did that now but nothing changed. I still can't access the files.

Anonymous

Anonymous Mon 17 Aug 2020 17:08:25 No.874076 Report

Quoted By: >>874078

>>874062
>>874075
Oh. Spoke too soon. I restarted explorer.exe and now it works.

Thanks!

Anonymous

Anonymous Mon 17 Aug 2020 17:12:14 No.874078 Report

Quoted By:

>>874076
...and now the lock is back. What the hell. It was gone and I was able to view the files, but then I closed the window and navigated back to the folder and it was locked again.

Anonymous

Anonymous Mon 17 Aug 2020 17:13:21 No.874079 Report

Quoted By: >>874084

>>874045
>I tried out Linux the other day and while I was in the distro (Mint) I wrote and read some stuff from an external HDD.
>When I access that HDD in Windows 10, all the files in the folder I accessed have a yellow lock on them and are unreadable.
If you're planning on sharing this drive between Linux and Windows, the correct solution is to mount it on Linux with "usermapping", so that when you use it on Linux it will create files that are owned by the same user as when you use it on Windows. In short, you run a little app on Windows to capture your on-disk username (or "SID", for example ::S-1-5-21-3141592653-589793238-462643383-1000), then create a file telling Linux that your Linux on-disk username on ext3 ("UID", for example "1001") is the same as your Windows SID. Without this usermapping option, Linux just makes some user up, which Windows then enforces.

https://www.tuxera.com/community/ntfs-3g-advanced/user-mapping/

The quick and dirty solution is to format it ExFAT, which has no concept of users or permissions.

Anonymous

Anonymous Mon 17 Aug 2020 17:17:31 No.874084 Report

Quoted By: >>874087 >>874092

>>874079
Will mounting it on Linux with usermapping make it so the files are accessible on Windows again?
I think I'll give up on Linux though. Too much that can go wrong even with the most basic of things.

I was so happy that I was able to access the files again but then it went back to not working again. God damn it.

Anonymous

Anonymous Mon 17 Aug 2020 17:26:59 No.874087 Report

Quoted By: >>874090

>>874084
>Will mounting it on Linux with usermapping make it so the files are accessible on Windows again?
It will make the problem not happen in the first place. You still need to fix the fallout from whatever permissions Linux set the first time though.

Your files should have an "inherited from" column in advanced security settings. If it's not "none", this is the object (probably a folder) you need to be taking ownership of and (if it's permissioned to a username not creator/owner) changing the permissions on.

Anonymous

Anonymous Mon 17 Aug 2020 17:44:11 No.874090 Report

Quoted By: >>874114

>>874087
>Your files should have an "inherited from" column in advanced security settings. If it's not "none", this is the object (probably a folder) you need to be taking ownership of and (if it's permissioned to a username not creator/owner) changing the permissions on.
Did this now, several times, but it didn't work.

Anonymous

Anonymous Mon 17 Aug 2020 17:47:27 No.874092 Report

Quoted By: >>874096

>>874084

>I think I'll give up on Linux though. Too much that can go wrong even with the most basic of things.

Inhowfar? The Windows thing? That's more a little interaction problem between two systems of which one does not recognise the other and therefore gets confused when the files suddenly changed because some outside system accessed them. If you plan to use Linux and Windows in parallel yeah you should probably configure it so the two get along, which obviously has to be done from Linux' part (or make the NTFS partition read-only or sth) but in itself it works fine. It's just indeed the case that Linux has the philosophy of giving the user more freedom which also means he has to know what he is doing. In my experience dual-boot systems get along very well.

Anonymous

Anonymous Mon 17 Aug 2020 17:49:36 No.874096 Report

Quoted By: >>874104

>>874092
I just want to be able to access the files in the folder on Windows 10 again.

I can access the rest of the HDD, just not the files in that folder.

Do I need to boot into Linux to unlock the files? If so, how do I do that? Keep in mind that I'm completely new to Linux so I have no idea how to do anything.

Anonymous

Anonymous Mon 17 Aug 2020 17:59:47 No.874104 Report

Quoted By: >>874107 >>874108

>>874096

Well as a temporary measure just to maybe get the files back while working on the issue itself you could try using the Linux system to copy them to a USB drive or sth. The Linux system obviously has access and when copying them they have to be written again with new permission flags etc. So maybe 10 will treat them then differently? Also maybe because they are on a USB drive and those typically contain data from other systems so enforcing the permission system on those would be very hindering, so maybe it treats them less strictly? Worth a shot I'd say.

Anonymous

Anonymous Mon 17 Aug 2020 18:05:49 No.874107 Report

Quoted By: >>874108

>>874104

Also, if the drive is using only FAT, (ex)FAT does not know permissions, so all files written by the system to it should then be freely accessible again.

Anonymous

Anonymous Mon 17 Aug 2020 18:07:02 No.874108 Report

Quoted By: >>874110 >>874111

>>874104
>>874107
So I basically need a second drive formatted in exFAT?

Anonymous

Anonymous Mon 17 Aug 2020 18:11:32 No.874110 Report

Quoted By: >>874112

>>874108
You could also try "understanding how Windows permissions work", but if that's too much hassle, an exFAT disk will certainly make the problem go away.

Anonymous

Anonymous Mon 17 Aug 2020 18:12:46 No.874111 Report

Quoted By: >>874127

>>874108

A simple USB stick not formatted as NTFS big enough to take the contents of the folder will do.
Could even be smaller but then you have to take multiple turns. Because you could THEN simply copy the chunk back while in Windows, since FAT does not know permissions the new copies will get the basic permissions with you being the owner again and then you can continue with the next batch.

Anonymous

Anonymous Mon 17 Aug 2020 18:13:05 No.874112 Report

Quoted By:

>>874110
I've tried understanding them but I just can't change anything.

Anonymous

Anonymous Mon 17 Aug 2020 18:13:53 No.874114 Report

Quoted By: >>874127

>>874090
Post a screenshot of the advanced security settings box for the object you can't access and the object(s) it inherits permissions from.

Anonymous

View Same Google ImgOps iqdb SauceNAO dgfwsdg.jpg, 124KiB, 1022x639

Anonymous Mon 17 Aug 2020 18:33:35 No.874127 Report

Quoted By: >>874148

>>874111
The folder is rather big so I'd have to get a big USB stick.

But yeah I'll go the FAT route.

Thanks.

>>874114

Anonymous

Anonymous Mon 17 Aug 2020 18:38:41 No.874131 Report

Quoted By: >>874133 >>874145

>>874045
>I tried out Linux
Stick to an os you can use.

Anonymous

Anonymous Mon 17 Aug 2020 18:39:56 No.874133 Report

Quoted By: >>874148

>>874131
Wow what an extremely helpful reply.

Anonymous

Anonymous Mon 17 Aug 2020 18:52:30 No.874145 Report

Quoted By: >>874147 >>874154

>>874131

Everone has to start somewhere sometime. I guess YOU jumped out of your mum's womb wearing a Tux shirt and compiling the kernel on your little Thinkpad, right?
Though I do wonder how OP made Linux fuck around with Windows' permissions without trying to chmod them or sth., just accessing the partition and opening some files should not do that.

Anonymous

Anonymous Mon 17 Aug 2020 18:55:24 No.874147 Report

Quoted By:

>>874145
>just accessing the partition and opening some files should not do that.

Yeah all I did was booting into Mint from an USB stick, browse the web, tried out some programs and watched a movie. And like I said, I only accessed that one folder on the external HDD.

Anonymous

Anonymous Mon 17 Aug 2020 18:56:47 No.874148 Report

Quoted By: >>874153

>>874127
Two things to try:

1- I'm pretty sure it shouldn't be owned by "Users", it should be owned by *a specific user*, for example whatever your username is
2- tick "replace all child object permissions with inheritable permissions from this object", apply.

Sorry I can't be more helpful, but I kinda assumed you'd leave intact what these were permissions for, and whether or not you can currently access it. If, for example, it's somewhere inside \users\, then it shouldn't be being set up as a source of inheritable permissions, it should be inheriting from where it's put, and you should be doing (2) on whatever is the actual source of inheritable permissions for where the object is. To be more concrete, if it's in \users\<you>\Documents, you should be doing (2) on \users\<you>\Documents, not on the secret mystery object.

>>874133
ironic.

Anonymous

Anonymous Mon 17 Aug 2020 18:59:54 No.874153 Report

Quoted By: >>874157

>>874148
So just [my username], not [my username]\Users?

And I did tick that.

Aaaand it doesn't work.

Anonymous

Anonymous Mon 17 Aug 2020 19:00:18 No.874154 Report

Quoted By: >>874170

>>874145
>just accessing the partition and opening some files should not do that.
It does on NTFS, because just like EXT, the file has to have *some permissions*, and if you don't set up a username mapping, Linux just guesses.

Just as you can't have a file on EXT that isn't owned and doesn't have permission bits, you can't have a file on NTFS that isn't owned and doesn't have an ACL.

In addition, Linux can't rename, it renames and moves by creating a new file then hardlinking the source data stream into it, then deleting the source file. This will create a new file with new permissions. This is distinctly different from windows' "move/rename the source file" semantics.

Anonymous

Anonymous Mon 17 Aug 2020 19:03:11 No.874157 Report

Quoted By: >>874162

>>874153
I'm really trying to help you, but you're not really helping me. You need to choose between operational secrecy and getting your problem solved, you can't have both.

The full unreadacted path of what I can't access is ___________________
It is owned by ___________________
Its ACLs are in the screenshot attached ___<pic related>____________

>>874153
>So just [my username], not [my username]\Users?
YOUR_COMPUTER_NAME\YOUR_USERNAME . Use the picker dialogue (>>874073) if you're not sure.

Anonymous

Anonymous Mon 17 Aug 2020 19:05:48 No.874162 Report

Quoted By: >>874166 >>874169

>>874157
>YOUR_COMPUTER_NAME\YOUR_USERNAME
Did that.

The owner is [username] ([computername]\username])
The access is "full control".
Inherited from is "none".

Anonymous

View Same Google ImgOps iqdb SauceNAO super secret documents.png, 20KiB, 623x467

Anonymous Mon 17 Aug 2020 19:13:15 No.874166 Report

Quoted By: >>874167

>>874162
Allow me to illustrate why your continuing refusal to state the filename you can't access is SO FUCKING UNHELPFUL:

This is a directory inside the user profile. It inherits permissions because it is supposed to inherit permissions. I know it is supposed to inherit permissions, because I, someone who knows what he's doing, know that objects that are here are supposed to do that.

Anonymous

Anonymous Mon 17 Aug 2020 19:15:43 No.874167 Report

Quoted By: >>874216

>>874166
It's literally just a folder on an external HDD.

>E:\Archive\Collection

Anonymous

View Same Google ImgOps iqdb SauceNAO super secret profile folder.png, 17KiB, 620x467

Anonymous Mon 17 Aug 2020 19:16:05 No.874169 Report

Quoted By: >>874172

>>874162
This is the directory of the user profile. It does not inherit permissions, instead its contents inherit from it. This is right and proper, because \users, \users\sandbox, and \users\bender_b_rodriguez should not have the same permissions.

Please, please, please help me help you. Just fill out the form and stop trying to decide what information I do and don't need. If you knew enough to work that out, you would know enough to solve your own problem without anyone's help.

The full unreadacted path of what I can't access is ___________________
It is owned by ___________________
Its ACLs are in the screenshot attached ___<pic related>____________

Anonymous

Anonymous Mon 17 Aug 2020 19:16:32 No.874170 Report

Quoted By: >>874173

>>874154

Yes but why would it modify all files in a folder or the folder itself just by reading it? I mean OP is surely just summarizing but it doesn't sound like too many write options in a random data folder.
Also this raises the (purely anecdotical) question why did it never happen to me? Linux and Windows(7) have always gotten along just fine, I work on my NTFS partition from Linux just as if I was on Windows and it does not care. Was I just lucky? Is 7 not as strict as 10 or does Mint do something different than Fedora?

Anonymous

Anonymous Mon 17 Aug 2020 19:20:03 No.874172 Report

Quoted By: >>874175 >>874216 >>874227 >>874237 >>874295

>>874169
The path is E:\Archive\Collection and the owner is Anon (ANON\Anon).
The list lists Users, (ANON\Anon), Authenticated Users, SYSTEM and Administrators (ANON\Administrators) and they all have full control and are inherited from none.

Anonymous

Anonymous Mon 17 Aug 2020 19:21:00 No.874173 Report

Quoted By:

>>874170
>just by reading it?
>>874045
>I wrote and read some stuff from an external HDD.

Anonymous

View Same Google ImgOps iqdb SauceNAO do this OP.png, 68KiB, 1001x672

Anonymous Mon 17 Aug 2020 19:23:58 No.874175 Report

Quoted By: >>874182 >>874227 >>874237

>>874172
>they all have full control and are inherited from none
That's not right. They should be inheriting from the root of the drive.

Open the E: drive's security page and do the "replace all child object permission entries with inheritable permission entries from this object" on it.

Anonymous

View Same Google ImgOps iqdb SauceNAO 9be54f5842.png, 8KiB, 484x217

Anonymous Mon 17 Aug 2020 19:37:16 No.874182 Report

Quoted By: >>874183 >>874185

>>874175
Did that and now the folder is inherited to E:\ but the files are still locked.

This error popped up while it was changing the permission, but it continued going when I dismissed it.

Anonymous

View Same Google ImgOps iqdb SauceNAO ITCrow[1].jpg, 58KiB, 625x336

Anonymous Mon 17 Aug 2020 19:42:31 No.874183 Report

Quoted By: >>874187

>>874182
>the files are still locked.
The full unreadacted path of what I can't access is ___________________
It is owned by ___________________
Its ACLs are in the screenshot attached ___<pic related>____________

The full unreadacted path of the object it inherits from is ___________________
It is owned by ___________________
Its ACLs are in the screenshot attached ___<pic related>____________

I'm not trying to bait you with this, it's just the information you're giving amounts to "it doesn't work", which is not sufficient information to solve your problem. Also do pic related before you go any further.

Anonymous

Anonymous Mon 17 Aug 2020 19:43:33 No.874185 Report

Quoted By:

>>874182
>This error popped up while it was changing the permission
This is expected, System Volume Information is owned by SYSTEM, which is a higher permission level than Administrator.

Anonymous

Anonymous Mon 17 Aug 2020 19:44:58 No.874187 Report

Quoted By: >>874192

>>874183
>it's just the information you're giving amounts to "it doesn't work"
Not really. I've given you everything except for my name which I won't post on 4chan no matter what.

Anonymous

Anonymous Mon 17 Aug 2020 19:53:16 No.874192 Report

Quoted By: >>874196

>>874187
Okay, hopefully someone else with more patience and less unreasonable demands will help you then. I'm fed up telling you precisely what information is required to diagnose your problem, and you kinda-sorta-but-actually-not supplying it. You were being asked for the bare minimum of information, and every item was absolutely necessary. By not providing one, you might as well have not been providing any.

Anonymous

Anonymous Mon 17 Aug 2020 20:05:33 No.874196 Report

Quoted By: >>874200 >>874205

>>874192
But I've given you the information you've asked for, sans my name.

Anonymous

Anonymous Mon 17 Aug 2020 20:14:15 No.874200 Report

Quoted By: >>874202

>>874196
I told you what information was needed, I explained to you why it was needed, and I even made you a little form to fill in (which you didn't do). No-one can read your mind through the internet, which is why you need to supply the information that's needed. If this is a dealbreaker for you, go pay someone.

Anyways, I'm out. I say this not to annoy you, just to save you wasting your time waiting for an answer that isn't coming.

Anonymous

Anonymous Mon 17 Aug 2020 20:19:20 No.874202 Report

Quoted By: >>874214

>>874200
>I told you what information was needed, I explained to you why it was needed
And I gave you the information EXCEPT for my name. Dude.

Anonymous

Anonymous Mon 17 Aug 2020 20:23:38 No.874205 Report

Quoted By: >>874207 >>874214

If the problem is really just the name-part which is always the same why would that then matter for the solution when it can just be regarded as a placeholder that OP can then fill in? Hell, even if i were two identity strings he could just use [name1] and [name2] and then fill the real ones in accordingly.

>>874196

However I got the feeling that before this is solved at the root you will have solved it via the FAT-drive method even when transferring one byte at a time... Not the most elegant way but it'll work.

Anonymous

Anonymous Mon 17 Aug 2020 20:25:10 No.874207 Report

Quoted By:

>>874205
Yeah I'll go with that. I have a couple of old empty internal HDDs lying around that I can reformat.

Anonymous

Anonymous Mon 17 Aug 2020 20:37:46 No.874214 Report

Quoted By: >>874216

>>874202
>And I gave you the information
No, you didn't.

The full unreadacted path of what I can't access is __DIDN'T EVEN MENTION__
It is owned by __DIDN'T EVEN MENTION__
Its ACLs are in the screenshot attached __DIDN'T POST__

The full unreadacted path of the object it inherits from is __DIDN'T EVEN MENTION__
It is owned by __DIDN'T EVEN MENTION__
Its ACLs are in the screenshot attached __DIDN'T POST__

>>874205
>However I got the feeling that before this is solved at the root you will have solved it via the FAT-drive method even when transferring one byte at a time... Not the most elegant way but it'll work.
Agreed, do the disk drive thing. It will certainly be quicker than trying to get two simple pieces of information out of OP's top-secret headquarters.

Anonymous

Anonymous Mon 17 Aug 2020 20:39:13 No.874216 Report

Quoted By: >>874227

>>874214
>The full unreadacted path of what I can't access is __DIDN'T EVEN MENTION__
>>874167
>>874172
>__DIDN'T EVEN MENTION__
>>874172
>Its ACLs are in the screenshot attached __DIDN'T POST__
>>874172

Anonymous

View Same Google ImgOps iqdb SauceNAO 360[1].png, 82KiB, 360x360

Anonymous Mon 17 Aug 2020 20:56:14 No.874227 Report

Quoted By: >>874232 >>874237 >>874252

>>874216
The one you can't access *NOW*. Even putting in "the same as last time" would have been better than the maximally-unhelpful "it's still locked". What's still locked? If you'd done >>874175 properly, >>874172 wouldn't be saying >>874172 because it would have been overwritten. Don't even get me started on your selective quoting: you were asked for the ACLs of a mere two objects, and your entire selective quotefest only refers to one of them.

Anyways, OP, it's been a hoot. Someone with the exact skillset you need to solve your problem offers to help you for free, and instead of getting it fixed in two minutes you act like someone put you on the stand. Go do the disk thing.

Anonymous

Anonymous Mon 17 Aug 2020 20:58:43 No.874232 Report

Quoted By: >>874237 >>874252

>>874227
>maximally-unhelpful "it's still locked"
How the hell is that unhelpful?
Everything everyone have told me in this thread hasn't worked.
The files are still locked.

Anonymous

Anonymous Mon 17 Aug 2020 21:06:29 No.874237 Report

Quoted By:

>>874232
>why is that unhelpful
>>874227
>If you'd done >>874175 properly, >>874172 wouldn't be saying >>874172 because it would have been overwritten.
I don't care about the answer, but go look for your own satisfaction, and you'll see why your answer was unhelpful. You were asked three very specific things about how two ACLs had changed and you didn't answer any of them.

Go do the disk thing.

Anonymous

Anonymous Mon 17 Aug 2020 21:29:51 No.874252 Report

Quoted By: >>874253 >>874254

>>874227

The post where OP stated what should have been overwritten was from BEFORE that advice, so before they could have been overwritten. Also we then had the System Volume Information complaining thing like it should be, so it is highly likely that OP really DID check that mark to let them inherit from root.

>>874232

You did really, super special chocolatey fudgy pinky fingers crossed promise, do the root inheritance thing on E, meaning checking that box letting all sub-folders and files inherit from the root, right?

Anonymous

Anonymous Mon 17 Aug 2020 21:37:19 No.874253 Report

Quoted By:

>>874252
>meaning checking that box letting all sub-folders and files inherit from the root, right?
Yes.

Anonymous

Anonymous Mon 17 Aug 2020 21:42:07 No.874254 Report

Quoted By: >>874284

>>874252
>The post where OP stated what should have been overwritten was from BEFORE that advice
That's my point, yes. He was asked what the ACLs were doing *now*, but apparently he felt that that information was classified, and what they were doing *before* should suffice.

>>874252
>You did really,...
I wish you luck, anon.

Anonymous

Anonymous Mon 17 Aug 2020 22:34:06 No.874284 Report

Quoted By: >>874294

>>874254
>but apparently he felt that that information was classified, and what they were doing *before* should suffice.
What? No.
I posted what their status are now.

Anonymous

Anonymous Mon 17 Aug 2020 22:48:23 No.874294 Report

Quoted By: >>874295

>>874284
>I posted what their status are now.
Then you must have done it so stealthily as to fool two separate people into thinking you didn't.

Anonymous

Anonymous Mon 17 Aug 2020 22:49:59 No.874295 Report

Quoted By: >>874299

>>874294
>>874172

Anonymous

Anonymous Mon 17 Aug 2020 22:55:14 No.874299 Report

Quoted By:

>>874295
Holy shit you're right, and you even posted it before it was asked for. Seeing as you can travel through time, why not just go get your disk from before you fucked it in Linux?

Capcode	All Only User Posts Only Verified Posts Only Moderator Posts Only Manager Posts Only Admin Posts Only Developer Posts Only Founder Posts
Show Posts	All Only With Images Only Without Images Only Spoiler Images Only Non-Spoiler Images
Deleted Posts	All Only Deleted Posts Only Non-Deleted Posts
Ghost Posts	All Only Ghost Posts Only Non-Ghost Posts
Post Type	All Only Sticky Threads Only Opening Posts Only Reply Posts
Results	All Grouped By Threads
Order	Latest Posts First Oldest Posts First

On these archives

Your latest searches

Locked files