3 ms·

Honestly, this should be obvious for anyone who has at least a bit of experience with Linux. It's the same reason why you use tar.[extension] when you create an

by mastazi 10y ago

Honestly, this should be obvious for anyone who has at least a bit of experience with Linux. It's the same reason why you use tar.[extension] when you create an archive - Tar saves the Linux metadata (ownership, permissions). To those who claim this need to be fixed, I want to ask: how? I mean if I modify a file in the Linux filesystem as a Windows user, what should the ownership be? Root? Some non-root user? Should we just make those files 777? Each of those solutions would bring more problems. It seems to me that there is no "one size fits all" fix here.

jaza 10y ago
For many years now, I've had one or two NTFS partitions on my dual-boot machine (Win7/Ubuntu), which are regular drives in Windows, and which are volumes mounted with all files set to 777 permissions in Linux. Have never had any problems with corruption, access denied, etc. Works great for volumes that mainly contain documents and media (and some Windows executables). But you can't mount "/" and co like that, and similarly, I can imagine that it would be inadequate for WSL, which stores many system files on NTFS, where many of those files have to use more restrictive permissions (e.g. 600 for many core binaries / configs), otherwise errors result.
userbinator 10y ago
I mean if I modify a file in the Linux filesystem as a Windows user, what should the ownership be? Inherited from the directory, like it is on Windows and Linux (by default)? And 777 is a perfectly fine default, since it's a good match for the Windows default attributes and ACLs. It seems to me that there is no "one size fits all" fix here. There isn't. But there is a sensible default, which is not "assumes the file is corrupted/damaged". Consider what happens in Linux if you mount a filesystem like FAT which doesn't even support all the extended metadata. No extended metadata does not mean "I can't do anything with the files", unlike what seems to be happening with WSL here.
- dozzie 10y ago
  > Inherited from the directory, like it is on Windows and Linux (by default)? Who lied you such horribly that under any unix a newly created file is owned by the owner of the directory? It's not even generally true for group ownership, which has a little more frivolous behaviour! > And 777 is a perfectly fine default 0777 permissions are never fine as a default. It's asking for security vulnerabilities.
verytrivial 10y ago
This should be top comment. If you want to preserve non-Linux attributes, you can NOT use tools that are unaware of how to handle the different assumptions made. If you don't mind smashing these attributes, go ahead, but don't cry foul. It is not broken. If you want to just transfer files for their content, there is a method provide in TFA, but that is not the matter at hand here. There is simply an impedance mismatch between how these operating systems view files. Sure, you can suggest a bunch of guesses about what to do if you edit or drop a file from one context into the other without both operating systems agreeing on how to manage that but you will find yourself arguing about what "sensible default" means until the cows come home.
- userbinator 10y ago
  If you want to just transfer files for their content, there is a method provide in TFA, but that is not the matter at hand here. It is. One can reasonably argue that it's natural for the parts that don't correspond between the two OSs to be lost in the transfer. But the main problem is that according to the article, it treats missing Linux metadata as an error. Sure, you can suggest a bunch of guesses about what 1to do if you edit or drop a file from one context into the other without both operating systems agreeing on how to manage that but you will find yourself arguing about what "sensible default" means until the cows come home. No doubt at MS there was probably large amounts of bikeshed over this, but I don't think "sensible default" should ever be "give up". Unfortunately, having been in a few design discussions with similar results, I have a good idea of exactly how that decision was reached: no one could agree on the precise behaviour, and "leave it out" or "make it an error" got chosen, simply because anything else would be perceived as supporting one alternative over another. Even randomly choosing one of the options would've been far preferable to having no option at all, to the surprise and disappointment of the users. Someone brought up a related issue at https://news.ycombinator.com/item?id=12981620 https://news.ycombinator.com/item?id=12981620 (HN discussion is at https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=11008449 ) in a different context, but it may have come from a similar (in)decision process: "we can't agree on a default, so let's just leave it as an error" --- nevermind the fact that in that case, it means bricking the user's machine, and imploring systemd to try to work around it.

by mastazi 10y ago

jaza 10y ago

For many years now, I've had one or two NTFS partitions on my dual-boot machine (Win7/Ubuntu), which are regular drives in Windows, and which are volumes mounted with all files set to 777 permissions in Linux. Have never had any problems with corruption, access denied, etc. Works great for volumes that mainly contain documents and media (and some Windows executables). But you can't mount "/" and co like that, and similarly, I can imagine that it would be inadequate for WSL, which stores many system files on NTFS, where many of those files have to use more restrictive permissions (e.g. 600 for many core binaries / configs), otherwise errors result.

userbinator 10y ago

I mean if I modify a file in the Linux filesystem as a Windows user, what should the ownership be? Inherited from the directory, like it is on Windows and Linux (by default)? And 777 is a perfectly fine default, since it's a good match for the Windows default attributes and ACLs. It seems to me that there is no "one size fits all" fix here. There isn't. But there is a sensible default, which is not "assumes the file is corrupted/damaged". Consider what happens in Linux if you mount a filesystem like FAT which doesn't even support all the extended metadata. No extended metadata does not mean "I can't do anything with the files", unlike what seems to be happening with WSL here.

dozzie 10y ago
> Inherited from the directory, like it is on Windows and Linux (by default)? Who lied you such horribly that under any unix a newly created file is owned by the owner of the directory? It's not even generally true for group ownership, which has a little more frivolous behaviour! > And 777 is a perfectly fine default 0777 permissions are never fine as a default. It's asking for security vulnerabilities.

verytrivial 10y ago

This should be top comment. If you want to preserve non-Linux attributes, you can NOT use tools that are unaware of how to handle the different assumptions made. If you don't mind smashing these attributes, go ahead, but don't cry foul. It is not broken. If you want to just transfer files for their content, there is a method provide in TFA, but that is not the matter at hand here. There is simply an impedance mismatch between how these operating systems view files. Sure, you can suggest a bunch of guesses about what to do if you edit or drop a file from one context into the other without both operating systems agreeing on how to manage that but you will find yourself arguing about what "sensible default" means until the cows come home.

userbinator 10y ago
If you want to just transfer files for their content, there is a method provide in TFA, but that is not the matter at hand here. It is. One can reasonably argue that it's natural for the parts that don't correspond between the two OSs to be lost in the transfer. But the main problem is that according to the article, it treats missing Linux metadata as an error. Sure, you can suggest a bunch of guesses about what 1to do if you edit or drop a file from one context into the other without both operating systems agreeing on how to manage that but you will find yourself arguing about what "sensible default" means until the cows come home. No doubt at MS there was probably large amounts of bikeshed over this, but I don't think "sensible default" should ever be "give up". Unfortunately, having been in a few design discussions with similar results, I have a good idea of exactly how that decision was reached: no one could agree on the precise behaviour, and "leave it out" or "make it an error" got chosen, simply because anything else would be perceived as supporting one alternative over another. Even randomly choosing one of the options would've been far preferable to having no option at all, to the surprise and disappointment of the users. Someone brought up a related issue at https://news.ycombinator.com/item?id=12981620 https://news.ycombinator.com/item?id=12981620 (HN discussion is at https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=11008449 ) in a different context, but it may have come from a similar (in)decision process: "we can't agree on a default, so let's just leave it as an error" --- nevermind the fact that in that case, it means bricking the user's machine, and imploring systemd to try to work around it.