7 ms·

FTA: > I have to provide this guidance at least 2-3 times a day so instead I am publishing it here so everyone can find / link-to this guidance. This may be o

• ad-hominem 10y ago
  From the article: "Remember: There’s a reason we gave the %localappdata%\lxss\ folder ‘hidden’ & ‘system’ attributes " So if you go messing about in hidden system folders, you get what you deserve.
  • josho 10y ago
    One could also argue that an editor that loses extended file attributes when editing a file is broken. I would have preferred msft to have posted an article explaining that files have attributes and editors must not loose those attributes when making edits.
    • jahewson 10y ago
      Files on Windows don't have attributes. Files on an NTFS volume may have extended attributes associated with them but you'll need to go out of your way to find them and doing so has never been a requirement of working with files on Windows. Not supporting an obscure non-mandatory thing hardly constitutes "broken". An editor which just kept the existing attributes would still end up with incorrect time stamps - so now all Windows apps need to know how to handle Linux file attributes? Nope - because these files were never meant to be edited by Windows apps. And it works best that way.
      • josho 10y ago
        I didn't realize extended attributes were such an obscure feature. I haven't been on windows for years, yet knew about this feature. I'm on OSX and every now and then see how apps are making interesting use of file attributes (e.g. tags, or remembering the cursor position of a text file when re-opening). So, I'm honestly surprised Windows isn't doing anything with this useful OS feature.
• mona3000 10y ago
  Yes, it's totally a design problem that users are fucking with files in a system hidden folder. I do that all the time, easy mistake to make.
  • zymhan 10y ago
    More like editing some config file under the WSL folder with Notepad++ and discovering you destroyed it.
    • tokenizerrr 10y ago
      > WSL folder Which has both the hidden and the system flag set. You have to change two explorer settings to even access the directory, one of said changed gives you a prompt warning you that it might be dangerous to enable it.
  • vacri 10y ago
    This is the bullshit I really don't miss from the Windows world. *nix: "Go for it, edit what you want, just be aware you can fuck up" Windows: "what the fuck are you doing in the special area? get out!"
    • ocdtrekkie 10y ago
      The only difference in assumption is that Linux users can safely assume most Linux users kinda know what they're doing. This is not true for Windows, where the default assumption is, you probably don't know what you're doing. ;) When you do know what you're doing, nobody complains about you going in the crevices. One of my favorite Windows v. Linux things is when Linux users try to work in Windows, and try and do things that would be perfectly normal in Linux, and then wonder why their Windows box is so unstable. I once ran across someone who tried putting their Windows\system32 folder into a version control app. When their Windows registry exploded spectacularly, their response was that this was a normal thing to do on a Linux box. Windows and Linux take very different engineering approaches to things, so skills developed in one don't necessarily translate well to the other.
• RubyPinch 10y ago
  the system attribute is that better defense, changing explorer's options to display such files results in the following warning https://i.imgur.com/uUaJEZI.png https://i.imgur.com/uUaJEZI.png if it was done via a VM, people would just mount the VHD, edit the files, and still complain
  • Eridrus 10y ago
    Microsoft puts so many things behind this flag that you pretty much have to display all system files if you are a power user.
    • wfunction 10y ago
      Totally disagree. I enable it on the rare occasions I need to and disable it immediately after I'm done doing what I need. This happens quite rarely (a few times a year) so, basically: no, I beg to differ.
    • cpayne 10y ago
      Hmm... I'm not too sure about that. Any examples? Show file extensions is disabled by default. I'll always go in and change that. But I can't think of a time where I've had to go into a system file before.
    • to3m 10y ago
      I've left the system files invisible at least since installing Windows 10, and it hasn't once been a problem. I can't remember if it was always this way, or if it's a recent addition, but there's a separate option for showing hidden files and folders. (With this ticked, system files remain hidden, so this one is a much easier tick to recommend, if you're technically-minded. You get to see %USERPROFILE%\AppData, which you'll probably want, but not stuff like hiberfil.sys and boot.ini, which you need much more rarely.)
    • Lazare 10y ago
      My experience is that this was arguably true in the NT/9x days, wasn't really true in the XP days, and is quite false with Windows 7 onwards. What exactly has caused you to need to unhide those files this decade?
• vesinisa 10y ago
  EDIT: Misinformed, see wfunction's comment below. I can understand their frustration, because this is probably really hard to fix. I guess there would not be problems if Windows apps were not overwriting files by first deleting them and then re-creating them with new contents. It's easy to see why this leads to data loss (file permission metadata is data in the Unix world). You rarely see Unix apps re-creating files: there you instead you specify the behaviour in case the file exists with the flags of the open(2) call. I guess such contract is absent / not as strict in the Windows world (disc: I have never programmed for Windows), which would make solving the conflicting APIs almost impossible: if a re-created file would inherit a previously deleted synonymous file's permissions, what happens to a program who is deleting a file exactly to get rid of its permissions? I think MS has done pretty impressive work with the Linux subsystem. It is certainly not a trivial task, and I am looking forward to seeing more awesome stuff running on Windows.
  • deleted 10y ago
    [deleted]
  • wfunction 10y ago
    > You rarely see Unix apps re-creating files: there you instead you specify the behaviour in case the file exists with the flags of the open(2) call. I think your lack of knowledge about this problem is betraying you. This is outright wrong. First, look up CreateFile() in Windows; it has flags to specify things like this as well. Second, the reason programs delete files in the first place has nothing to do with the lack of such flags. It has to do with the fact that they want to write new contents but don't want to lose data in the event of an abnormal termination. If you truncate the file that you're opening instead, then you lose that data if something goes wrong. So they create a new file and replace it with the old one when it's written. Finally, as far as I know, 'nix tools have a tendency to outright replace files MORE than Windows tools do. That's why the underlying Windows kernel API function (NtCreateFile/ZwCreateFile) has a FILE_SUPERSEDE parameter... whose entire intention is to mimic POSIX behavior: > The CreateDisposition value FILE_SUPERSEDE requires that the caller have DELETE access to a existing file object. If so, a successful call to ZwCreateFile with FILE_SUPERSEDE on an existing file effectively deletes that file, and then recreates it. [...] Note that this type of disposition is consistent with the POSIX style of overwriting files. https://msdn.microsoft.com/en-us/library/windows/hardware/ff566424.aspx https://msdn.microsoft.com/en-us/library/windows/hardware/ff...
• mikeash 10y ago
  Maybe they're working on that too. Writing a blog post to warn people about a problem doesn't preclude fixing it.
• sgift 10y ago
  > Remember: There’s a reason we gave the %localappdata%\lxss\ folder ‘hidden’ & ‘system’ attributes They already did that, but as usual "with great power comes great responsibility", so if you ignore the safeguards installed .. well .. bad things can happen.
  • ocdtrekkie 10y ago
    Indeed, even with my level of tinkering, I almost am never dealing with system attribute files. The cool thing is that Microsoft ALLOWS you to do anything with your computer, they don't hold the sort of superiority complex other companies do about telling you what you can and can't do on your own PC[0]. So yes, if you decide to grant yourself permission to see and modify those files, you can give yourself a bad time. Or maybe you could develop an application that handles them intelligently, after researching how they work extensively. [0]Someone's gonna ask: With the right amount of registry and file tampering, yes, you can absolutely render automatic updates and telemetry nonfunctional. Results may vary, but it's definitely doable.
    • jsjohnst 10y ago
      I have to assume you are alluding to Apple when you say "other companies". If that's correct, it's relatively trivial to disable the protections on system files in all versions of OS X / macOS. Furthermore, automatic updates and Apple's less invasive version of telemetry are both opt-in, not opt-out and certainly not requiring the magic mojo Windows requires to do so. Sure, iOS is a police state in comparison, but you explicitly stated "on your own PC", not mobile device.
      • ocdtrekkie 10y ago
        I was actually thinking of Google at the time. Chrome OS devices, for example, wipe themselves if a system file is changed. The new Pixel needed an exploit to root it. Companies like Google (and yeah, Apple too to some degree) believe that you should only experience your own computer the way they intended it to be experienced.
• colemickens 10y ago
  Short of literally removing admin access to the box, how would they go about fixing this?
  • ChuckMcM 10y ago
    One way would be to run a user level nfsd on the Linux side and mount it on the windows side as an nfs share. Or if they are morally opposed to that running a user level samba server and mounting it as a CIFS share. Both of these solutions allow you to access Linux files from windows apps on their native storage layer without corrupting them or the system they are running on. You might be able to accomplish that with a system service that runs in the context of the LXX shim and a local (in memory) network connection.
• mdip 10y ago
  I have to agree with you there. I've always used the 80/20 rule for prioritizing immediate fixes: If I have to take a support call from more than 20% of the people I hae deployed my software to (and in some cases, this may amount to one customer), then whatever the circumstance is, it's treated as a high priority bug. That said, Windows Subsystem for Linux is beta and they went out of their way to make that clear -- going so so far as to put (beta) in the Add Features dialog. And this was the right move, IMO. Such a small percentage of their user base use this feature -- it's targeted at us and we're used to dealing with beta problems. They hit a large enough number of users to test the feature thoroughly, while managing expectations that it's not ready for prime time, yet. > "Silly users, stop trying to do things we didn't plan for you to do!" Yep, that's pretty much it. But in the context of a beta product, it's more "Here's something we are getting large numbers of reports about while we're refining the software for production release. In the meantime, don't do this." Now, if they release this production with that limitation and nothing to prevent you from destroying your data if you modify that folder, that'd be a major oversight, but I have a feeling that'll be resolved. My hope would be that you'd be able to mess with these files using whatever tool you wish, but even adding a dialog to Explorer, and an error in PowerShell/Cmd that catches you trying to do something that'll break the subsystem would be an improvement.
  • pdonis 10y ago
    > in the context of a beta product, it's more "Here's something we are getting large numbers of reports about while we're refining the software for production release. In the meantime, don't do this." I don't see any indication in the article that this behavior is something they intend to change in order to "fix" a "problem". It looks to me like don't do this, period.
    • bitcrazed 10y ago
      If/when this issue is resolved, the guidance will be updated. Until then, don't go futzing with files in hidden system folders.
• ChuckMcM 10y ago
  I think you are being a bit too harsh here, there is a way in which it does work, all of your files are on the "windows" side. For those of us who have lived in both camps (windows and Linux) the difference in file meta-data is extreme, it isn't an "easy" problem at all. Windows has metadata bits for all sorts of things that Linux doesn't which gives it much greater flexibility but means that the equivalent of your umask on Windows doesn't translate. It does however do everything Linux / POSIX needs so the inverse is doable.
  • bphogan 10y ago
    "for those of us who have lived in both camps" I live in both camps. This is the same attitude I took issue with in the original article. It's condescending. "I have to keep telling you to not do something because we didn't plan for it." I'm not saying it's an easy problem. But I am saying that blaming users for something doesn't give me confidence.
    • hetman 10y ago
      That's like having users start deleting things out of your /usr/lib and then complaining the fault is clearly with the OS designers for not securing that folder sufficiently.
      • jacobush 10y ago
        That's a valid position though. Maybe iOS is for those folks.
• RichardCA 10y ago
  "I've been using WSL since the beta, and using Vagrant + Putty gives me better results." If WSL can't do the equivalent of Vagrant-style vm.synced_folder, how is anyone expected to use it for a real-world workflow? I've found the combination of Vagrant/Virtualbox with the Git command-line tools (using MSYS2) to be an excellent cross-platform working environment. Really, it's been my daily workhorse for the past two years. Also, there is a not-free program called SecureCRT which is much more usable than Putty.
  • erk__ 10y ago
    I like mobaXTerm it is pretty useable and have a free version.