Microsoft still hasn't figured it out.







  • Seriously, it's your operating system. It's your software. You should be the FIRST people to figure out how to run programs without rebooting.



  • I don't think it's a matter of "not knowing", I think it's a matter of technical support. Most of the time when you get this message it's because new services have been added and others need to be restarted to load new environment variables or whatnot; odds are that for most people things will work out immediately, but instead of having to support people who have to troubleshoot services that did not restart or who have resources to unlock they figure it's much easier to tell people to reboot.

    Someday when you start working you will see. Lying to users to make your life easier happens and can be cost-effective.

    As for rebooting: it's not wrong per se. It's annoying if you have to do it often but did you try rebooting Windows 8 on a recent laptop? It's so fast, at first it feels like it did not reboot.



  • @Ronald said:

    I don't think it's a matter of "not knowing", I think it's a matter of technical support. Most of the time when you get this message it's because new services have been added and others need to be restarted to load new environment variables or whatnot; odds are that for most people things will work out immediately, but instead of having to support people who have to troubleshoot services that did not restart or who have resources to unlock they figure it's much easier to tell people to reboot.

    Someday when you start working you will see. Lying to users to make your life easier happens and can be cost-effective.

    As for rebooting: it's not wrong per se. It's annoying if you have to do it often but did you try rebooting Windows 8 on a recent laptop? It's so fast, at first it feels like it did not reboot.

    Why does Visual Studio change services? It's a fucking IDE. IDEs should not need to run things while they're not open.



  • @Ben L. said:

    @Ronald said:

    I don't think it's a matter of "not knowing", I think it's a matter of technical support. Most of the time when you get this message it's because new services have been added and others need to be restarted to load new environment variables or whatnot; odds are that for most people things will work out immediately, but instead of having to support people who have to troubleshoot services that did not restart or who have resources to unlock they figure it's much easier to tell people to reboot.

    Someday when you start working you will see. Lying to users to make your life easier happens and can be cost-effective.

    As for rebooting: it's not wrong per se. It's annoying if you have to do it often but did you try rebooting Windows 8 on a recent laptop? It's so fast, at first it feels like it did not reboot.

    Why does Visual Studio change services? It's a fucking IDE. IDEs should not need to run things while they're not open.

    VS 2013 is in preview mode (look at your own screenshot). So instead of being a little bitch about it why don't you go on Connect to share your experience and suggest that they review the setup process. Odds are that it was simply your machine that needed an update of the .Net framework and either DLLs that were in use needed to be replaced or some system service was holding on resources that had to be reloaded. Or something.



  • @Ronald said:

    I don't think it's a matter of "not knowing", I think it's a matter of technical support. Most of the time when you get this message it's because new services have been added and others need to be restarted to load new environment variables or whatnot; odds are that for most people things will work out immediately, but instead of having to support people who have to troubleshoot services that did not restart or who have resources to unlock they figure it's much easier to tell people to reboot.

    Someday when you start working you will see. Lying to users to make your life easier happens and can be cost-effective.

    As for rebooting: it's not wrong per se. It's annoying if you have to do it often but did you try rebooting Windows 8 on a recent laptop? It's so fast, at first it feels like it did not reboot.

     

    So the real WTF is that it might work for some users, but will not work for some other users?

    I agree with Ben L. here on the services bit. Which other applications do you have to reboot your PC for these days? Not that many, I can tell you. But you cleverly avoided the question why an IDE would need services with an attack on his person.

     



  • up 7 days, 45 min, 1 user

    And during this time I've uninstalled nginx, installed Apache, MySQL, PHP, Android Studio (to try it out) and a new version of Eclipse. Without rebooting a single time. Talk about broken software and I'll show you a WHOLE operating system.



  • @Ronald said:

    did you try rebooting Windows 8 on a recent laptop? It's so fast, at first it feels like it did not reboot.
    Rebooting may be fast, but it still forces you to close down every other program you were using, even if they are at a point where data cannot be saved/resumed yet. Eg. part way through some number crunching, not yet reached a savegame, in the middle of some important communication that needs you to remain online, etc.. It's not just about maintaining uptime (my personal Linux record of 5 months ended when someone dropped a CD on the power switch, while I have gone for a couple of months on Windows 7). Sometimes there's actual data loss and annoying inconvenience associated with reboots. They should be kept to an absolute minimum, and if possible avoided completely. Installing an IDE certainly has no place demanding a reboot.


  • Discourse touched me in a no-no place

    @ubersoldat said:

    up 7 days, 45 min, 1 user

    And during this time I've uninstalled nginx, installed Apache, MySQL, PHP, Android Studio (to try it out) and a new version of Eclipse. Without rebooting a single time. Talk about broken software and I'll show you a WHOLE operating system.

    My previous laptop had a record uptime of nearly a year. Haven't had the current one long enough yet to have anything other than a trivial uptime (and it's had a few issues with hanging display drivers, which hasn't helped).


  •  Reboots are for Hardware changes only!



  • @Ronald said:

    Lying to users to make your life easier
    In my experience users lie, all the time, so yeah why not lie to them ^^



  • @Ben L. said:

    Why does Visual Studio change services? It's a fucking IDE. IDEs should not need to run things while they're not open.
    It only asks for a reboot when it has to update/install the .NET Framework.

    Maybe it shouldn't do that and expect users to install it by themselves. I mean, it's just a fucking IDE, right?

     



  • @pbean said:

    I agree with Ben L. here on the services bit. Which other applications do you have to reboot your PC for these days? Not that many, I can tell you. But you cleverly avoided the question why an IDE would need services with an attack on his person.
    It's just more evidence for my hypothesis that Ronald is a pseudonym of Steve Ballmer.

     



  • @Ben L. said:

    Seriously, it's your operating system. It's your software. You should be the FIRST people to figure out how to run programs without rebooting.
    You probably had something running that locked the files the installer was updating. VS 2013 installed without requiring a reboot here.



  • Ben, your PC either required the installation of services or updates to .dll files that were in use at the time of deployment.  Visual Studio usually includes an installation of MS SQL Server express, new .net frameworks, and/or other software with lower level hooks to the operating system for debugging purposes. Some users (developers, mostly), will not recieve the reboot message as they either run the installation without any other software running, or have already installed the other software and updates as part of a prior packages installation.

    Restarting he Computer is unnecessary probably about 90% of the time, even when in use .dll's are updated or new services installed; the restart message is so that the other 10% of users don't flood the forums and tech support lines with complaints.



  • @Medezark said:

    Ben, your PC either required the installation of services or updates to .dll files that were in use at the time of deployment.  Visual Studio usually includes an installation of MS SQL Server express, new .net frameworks, and/or other software with lower level hooks to the operating system for debugging purposes. Some users (developers, mostly), will not recieve the reboot message as they either run the installation without any other software running, or have already installed the other software and updates as part of a prior packages installation.

    Restarting he Computer is unnecessary probably about 90% of the time, even when in use .dll's are updated or new services installed; the restart message is so that the other 10% of users don't flood the forums and tech support lines with complaints.

    ^^^ This ^^^

    And, assuming that the installer needs to overwrite files that are in use by another app, imagine how all twisted your underwear would get if it started closing all these apps for you, so it could overwrite the files? You'd be on here getting all mildly-moist and shouting "...and it closed WORD! And CHROME! And Outlook! And ((shudder)) STEAM! BASTARDS!"

    So rather than try to get your authorisation to close each and every app (and you'd just refuse anyway, wouldn't you?) it's better to just restart the whole train.



  • @skotl said:

    And, assuming that the installer needs to overwrite files that are in use by another app, imagine how all twisted your underwear would get if it started closing all these apps for you, so it could overwrite the files? You'd be on here getting all mildly-moist and shouting "...and it closed WORD! And CHROME! And Outlook! And ((shudder)) STEAM! BASTARDS!"
    Still, why should an IDE replace widely used DLLs?

    Anyway, just to piss off both sides: a dev should be prepared to reboot his workstation/laptop/tablet/phone/watch at any given moment.

     



  • @skotl said:

    And, assuming that the installer needs to overwrite files that are in use by another app, imagine how all twisted your underwear would get if it started closing all these apps for you, so it could overwrite the files? You'd be on here getting all mildly-moist and shouting "...and it closed WORD! And CHROME! And Outlook! And ((shudder)) STEAM! BASTARDS!"
     

     

    Why should it need to shut existing software down just because an open file has been replaced.

    Try it on linux sometime, nothing happens becuase the old file remains visible to the program that opened it untill it is closed.

    Hell I can even SSH into a remote system, shut down the SSH service, sedit the  remote ssh config file & restart the ssh service all without tears


  • ♿ (Parody)

    @TGV said:

    Still, why should an IDE replace widely used DLLs?

    In this case, as was mentioned, you're getting more than just the IDE. It may very well be updating the .NET framework / runtime stuff, which are widely used. You'e not just getting a fancy text editor combined with a compiler.



  • @skotl said:

    assuming that the installer needs to overwrite files that are in use by another app, imagine how all twisted your underwear would get if it started closing all these apps for you, so it could overwrite the files? You'd be on here getting all mildly-moist and shouting "...and it closed WORD! And CHROME! And Outlook! And ((shudder)) STEAM! BASTARDS!"

    So rather than try to get your authorisation to close each and every app (and you'd just refuse anyway, wouldn't you?) it's better to just restart the whole train.

    Getting authorization is [b]exactly[/b] what it should do. "The following applications are using files that need to be replaced: <list>. Installation of Visual Studio will not complete until those applications are closed. Would you like the installer to close them for you?"

    If you say no, it should monitor the apps and, when the last one has closed, prompt you again. "The last application using a file that will be replaced by the installation of Visual Studio has been closed. Would you like to complete the installation now?"

    Using this approach, you are telling the user WHY you need to do what you're doing and giving them a choice about how to do it, instead of treating them like a mushroom.



  • @ip-guru said:

    Hell I can even SSH into a remote system, shut down the SSH service, sedit the remote ssh config file & restart the ssh service all without tears

    That would get fun if your internet connection was shaky.


  • Considered Harmful

    @Ben L. said:

    @ip-guru said:
    Hell I can even SSH into a remote system, shut down the SSH service, sedit the remote ssh config file & restart the ssh service all without tears

    That would get fun if your internet connection was shaky.

    I think I'd be holding my breath the whole time.



  • @boomzilla said:

    @TGV said:
    Still, why should an IDE replace widely used DLLs?

    In this case, as was mentioned, you're getting more than just the IDE. It may very well be updating the .NET framework / runtime stuff, which are widely used. You'e not just getting a fancy text editor combined with a compiler.

    Yeah, except neither Steam nor Chrome use the .NET framework, and Visual Studio can close any other program it likes. Hell, it can even close those two since they can start back up where they left off.



  • @RobFreundlich said:

    Using this approach, you are telling the user WHY you need to do what you're doing and giving them a choice about how to do it, instead of treating them like a mushroom.

    The mushroom people have always been Microsoft's target demographic; Windows 8 is the unfortunate natural consequence of this fact.


  • Considered Harmful

    @flabdablet said:

    The mushroom people have always been Microsoft's target demographic;


    I thought that was Nintendo.



  • @joe.edwards said:

    @Ben L. said:
    @ip-guru said:
    Hell I can even SSH into a remote system, shut down the SSH service, sedit the remote ssh config file & restart the ssh service all without tears
    That would get fun if your internet connection was shaky.
    I think I'd be holding my breath the whole time.
     

     

    I said can, I didnt say it would be considered best practice, if I absolutly had to I would edit the config tine first & then issue a restart to the ssh Daemon rather than manualy stopping & restartin.

     

    The point is that even replacing a file that is in use by another application is technicaly possible, but windows has not been writen to allow it because it is sdesigned as a single user os & rebooting one user is not a major issue.

     



  • @joe.edwards said:

    @Ben L. said:
    @ip-guru said:
    Hell I can even SSH into a remote system, shut down the SSH service, sedit the remote ssh config file & restart the ssh service all without tears

    That would get fun if your internet connection was shaky.

    I think I'd be holding my breath the whole time.

    Since Australium's last reboot, I've uninstalled the kernel, changed the distribution from testing to unstable, installed a new kernel, and updated all my software several times. All over ssh.



  • @Ben L. said:

    Since Australium's last reboot, I've uninstalled the kernel, changed the distribution from testing to unstable, installed a new kernel, and updated all my software several times. All over ssh.

    You realise you still need to do a reboot for those kernel changes to take effect, right?



  • @flabdablet said:

    @RobFreundlich said:
    Using this approach, you are telling the user WHY you need to do what you're doing and giving them a choice about how to do it, instead of treating them like a mushroom.

    The mushroom people have always been Microsoft's target demographic; Windows 8 is the unfortunate natural consequence of this fact.

    Yep - for those of us who (hopefully) know what we're doing, then displaying a list of apps (as Ben suggests) is pretty reasonable. For the rest of the population, though, it's just too complex for their tiny minds to cope with - hence "we're gonna virtually press the big red reset button now - you ok with that?".

    And for the record, I love Linux so all of the above is really just a commentary on where we are with Windows, really...



  • Core design flaw of Windows.

    Faced with the problem of multiple processes being able to access a file at the same time (as happens in multi-process-able operating systems) there arises the potential problem of those different processes getting confused when the file changes. Some operating systems wash their hands of the issue (or, maybe to be fair in a historical context, ignore it) and just make it the applications problem. e.g. "If you open a file for reading, be prepared to handle that the file might change under you."

    Windows took a different approach (arguably, one with 20-25 years of real world evidence suggesting that the OS "solve" this "problem") by making it possible that any process that has access to read a file has implicit access to write lock it. e.g. application no longer need to deal with files being changed on them, because if they can read the file, they can enforce that the file never changes. (even if they can't write to the file).

    Problem solved.

    Oh, except that their is no (easy?) way to know which processes have that write-lock in place, and/or no easy way to get those processes to release the lock. Thus, this problem. Windows has some extra complicated "schedule this file to change later" process, used (especially) for installs/upgrades, with processes actually being scheduled at reboot.

    I wonder what VMS did?



  • @RangerNS said:

    Windows took a different approach (arguably, one with 20-25 years of real world evidence suggesting that the OS "solve" this "problem") by making it possible that any process that has access to read a file has implicit access to write lock it. e.g. application no longer need to deal with files being changed on them, because if they can read the file, they can enforce that the file never changes. (even if they can't write to the file).

    Are you suggesting that a read lock shouldn't prevent another program from changing a file while it's being read?


  • Discourse touched me in a no-no place

    The Unix approach is to differentiate between the file and the thing indicated by a filename. The name can be rebound to a different set of contents without disturbing those processes that already have the file open; they continue to see the old contents. When the time to update to use the new contents comes, you can send the processes a message (err, a SIGHUP signal by convention) and it will reload everything. As long as you're not changing the binary itself, you can reload and everything keeps ticking. Sure, some things are problematic to reload this way, notably the C library, but they're not updated very often. (Thank god!)

    There's also a mechanism whereby a user with appropriate permissions (i.e., the administrator) can find out what processes have a particular file open. This can be useful. It's certainly possible to do something similar in Windows; I remember having a tool to do it a number of years ago, even if I forget its name right now.


  • Discourse touched me in a no-no place

    @dkf said:

    It's certainly possible to do something similar in Windows; I remember having a tool to do it a number of years ago, even if I forget its name right now.
    Process Explorer?



  • @dkf said:

    There's also a mechanism whereby a user with appropriate permissions (i.e., the administrator) can find out what processes have a particular file open. This can be useful. It's certainly possible to do something similar in Windows; I remember having a tool to do it a number of years ago, even if I forget its name right now.


    There are several third-party utilities to do it, but apparently Windows itself can't.

    Error: file can't be deleted because it's currently opened in another process. Good luck finding out which one!



  • I think that it can, but wrapping things up, whereas the convention with UNIX is that SIGHUP means "reload datafiles", there is no such convention in Windows. Because Windows promises that files will never change after you write-lock them. I guess you could try and "restart" processes that have write-locked files, even just killing them, but again, that isn't a standard/conventional flow. I mean, how can the OS be expected to figure out the inter-relationships between a bunch of processes, together providing some functionality? You can't just start killing off processes and expect that they will gracefully restart their IPC, or are atomic, or whatever. Reboot at least is a case that all applications should handle.

    Absence of write-locks it is an actual problem. UNIX just ignores it. Windows prevents it. UNIX applications (and maybe even UNIX defined convention, e.g. SIGHUP) deal with it gracefully. The Windows solutions opens up an entirely new set of problems, especially compounded by the (now largely historical) problem of just about every application installer installing files everywhere and unpredictably.



  • So TRWTF is that MS failed to enumerate the reason(s) why a reboot was necessary, prompting our speculation. The correct way to handle this sort of thing is to identify components that will have to be written to in order to complete the installation prior to starting installation, and inform the user of any conflicts related to write-locks etc. so that he/she may try to resolve them; at the very least this will promote educated users who can solve their own problems or at least have detailed error data for tech support if/when they call -- see the Linux community for real life examples :) Also, if we're bashing Microsoft I think the fact that they still include spaces in default executable paths is a worthier object of ridicule...



  • @ip-guru said:

     Reboots are for Hardware changes only!

     

    And for testing your startup scripts.

    Don't forget that, or those scripts will be tested when the UPS runs out at january 1st, 00:31 and you are at least a thousand kilometers away.

     



  • @RangerNS said:

    UNIX just ignores it.
     

    Not quite so. UNIX has a session semantics for reading, concurrent semantics for writting.

     Windows has lock semantics for everything, and pays the price.



  • @Salamander said:

    Are you suggesting that a read lock shouldn't prevent another program from changing a file while it's being read?

    No, I'm suggesting that something that has the very minor permission to read a file should not be allowed to lock it. Perhaps their should be an additional lock permission or something. Or if you build an OS that providing the functionality of an OS enforced lock, then also build the required related functionality of telling things that someone else really, really, wants to update the file. Or define an API and/or convention to break those locks, short of rebooting. You know, finish the job.



  • @anonymous235 said:

    Error: file can't be deleted because it's currently opened in another process. Good luck finding out which one!

    How old is your Windows?

    On my Windows 7 machine, when I delete a file and it is opened in another process (which has an open window), the name of the process/window is shown and it suggests that I should close the program before hitting Retry.

    Since I have no Win7 VM here with English language pack and you won't be able/willing to read my native language anyway, I decided not to post a screenshot (and in 2008R1 where I have access to machines with English language pack, I don't see these messages).

    And I'm confident it is nothing the program has to do - a quickly hacked up C# program or a PowerShell script ("is currently opened in Windows PowerShell") worked as well.



  • @mihi said:

    @anonymous235 said:
    Error: file can't be deleted because it's currently opened in another process. Good luck finding out which one!

    How old is your Windows?

    On my Windows 7 machine, when I delete a file and it is opened in another process (<font size="4">which has an open window</font>), the name of the process/window is shown and it suggests that I should close the program before hitting Retry.

    Yes this is true.  But, not every file that is being used by one or more processes has an open window. (most don't)  And that's the problem.

    Raymond Chen

    There was no way to find out which process has a file open. A file object has a reference count, and when the reference count drops to zero, the file is closed. But there's nobody keeping track of which processes own how many references. (And that's ignoring the case that the reference is not coming from a process in the first place; maybe it's coming from a kernel driver, or maybe it came from a process that no longer exists but whose reference is being kept alive by a kernel driver that captured the object reference.)

    This falls into the category of not keeping track of information you don't need. The file system doesn't care who has the reference to the file object. Its job is to close the file when the last reference goes away.

     



  •  Okay, opinion time: Given that you have to change the PATH/bashrc/whatever config bullshit your system uses. Do you prefer that:

    a) Setup tries to close all applications that are using PATH/bla-syscalls currently

    b) Setup requires a restart

    c) Setup continues without doing anything, so your applications try to start the old version of PATH

    d) Applications have to reread all configs everytime they use them



  • @Salamander said:

    @Ben L. said:
    Since Australium's last reboot, I've uninstalled the kernel, changed the distribution from testing to unstable, installed a new kernel, and updated all my software several times. All over ssh.

    You realise you still need to do a reboot for those kernel changes to take effect, right?

    Forget updating for kernel changes. Even a regular library update can break things randomly until you identify and terminate the application that's still using half the old libraries and/or log out and back in again! For example, a KDE upgrade (even a point upgrade) sometimes makes KDE applications (say, Kate) become unable to start because the application ends up loading a slew of old and new libraries - you get a cryptic error that some KPart is not found, couldn't be loaded, etc.

    The people who gloat about not rebooting their boxes / restarting the revelant applications across upgrades always amuse me, because they're effectively not updating at all. The Windows method makes it clear that you can continue to work without restarting, but the update won't take effect until you do.



  • @RangerNS said:

    No, I'm suggesting that something that has the very minor permission to read a file should not be allowed to lock it.

    That is a (historical) design decision. If you ignore the precedent that Unix does it the way it does, it kinda makes sense that a file is a resource, so accessing it in any form (read or write) can be expected to be exclusive, unless the one doing the access judges it all right for others to access it at the same time.

    @RangerNS said:

    Perhaps their should be an additional lock permission or something.

    Already exists (the dwShareMode parameter). You can specify that you want the file to be opened with a sharing mode that allows other processes to access it. The default of 0 just happens to mean "no sharing allowed" because of the above design decision.

    @RangerNS said:

    Or if you build an OS that providing the functionality of an OS enforced lock, then also build the required related functionality of telling things that someone else really, really, wants to update the file.

    By default, people don't write programs that are re-entrant in such a way. You mentioned Unix programs reload configs on SIGHUP but this also has to be explicitly coded into programs, so very few programmers do it. I am not aware of any program I use that supports it, for example.

    @RangerNS said:

    Or define an API and/or convention to break those locks, short of rebooting. You know, finish the job.

    The case you're talking about - updating - specifically involves DLLs loaded by the process, which means the process that's using them needs to be restarted. In the specific example we're dealing with here (.Net update), this "process" happens to be every .Net application on the system as well as the system itself.

    You will also find that most installers do tell you which applications are running and need to be closed first (I don't know if this is a feature of the OS, the default installer framework, or implemented individually by every installer. The point is it's doable and it is commonly done). The reason the VS installer doesn't tell you which applications to close so that it won't restart is, as I said, the "application" that's using the DLLs it needs to update is Windows itself.



  • @ip-guru said:

    The point is that even replacing a file that is in use by another application is technicaly possible, but windows has not been writen to allow it because it is sdesigned as a single user os & rebooting one user is not a major issue.

     

     

    On a Windows XP system, you could rename locked files and then drop in updated versions of that file with the old name. NTFS has an inode-vs-filename distinction because of the POSIX subsystem that was designed back in the days of NT4 (to get the government contracting dollar).

     



  • @ccj said:

    So TRWTF is that MS failed to enumerate the reason(s) why a reboot was necessary, prompting our speculation. The correct way to handle this sort of thing is to identify components that will have to be written to in order to complete the installation prior to starting installation, and inform the user of any conflicts related to write-locks etc. so that he/she may try to resolve them;

    The components that have to be written to are core OS components. The resolution is to restart the OS.

    @ccj said:

    at the very least this will promote educated users who can solve their own problems or at least have detailed error data for tech support

    The whole point of suggesting restarts is to avoid tech support calls.

    @ccj said:

    Also, if we're bashing Microsoft I think the fact that they still include spaces in default executable paths is a worthier object of ridicule...

    You argue about the lack of freedom and choice and then proceed to give an example of one yourself.



  • @ccj said:

    Also, if we're bashing Microsoft I think the fact that they still include spaces in default executable paths is a worthier object of ridicule...
    A space is a perfectly legitimate character and there is nothing wrong with it being used. Microsoft deserves to be criticized for a lot of things, but this is not one of them.  I would argue just the opposite -- the target of ridicule should be programs which, in the year 2013, cannot be installed in a directory whose name contains spaces. If your application is more retarded than Windows 95 then you are TRWTF.


  • Considered Harmful

    @El_Heffe said:

    @ccj said:

    Also, if we're bashing Microsoft I think the fact that they still include spaces in default executable paths is a worthier object of ridicule...
    A space is a perfectly legitimate character and there is nothing wrong with it being used. Microsoft deserves to be criticized for a lot of things, but this is not one of them.  I would argue just the opposite -- the target of ridicule should be programs which, in the year 2013, cannot be installed in a directory whose name contains spaces. If your application is more retarded than Windows 95 then you are TRWTF.


    It's more of a PITA for shell scripts (which really get used for more than they should). Escaping perfectly is damned tricky.



  • @anonymous235 said:

    Error: file can't be deleted because it's currently opened in another process. Good luck finding out which one!
    Argh! My personal favorite is trying to remove a flash drive.

    The device is in use.

    No, it's not. Not a single application is using it.

    Well, yes, it is; it seems a background "recording manager" application gets started when writing to the drive. It doesn't let go when it's done; I guess just in case I might want to write to it again, someday. (Hint: It's a removable drive; I might also want to, I dunno, remove it someday.) The only solution is to find the process in Task Manager and kill it. Or just ignore the message and yank the dumb thing out anyway.

     



  • @joe.edwards said:

    It's more of a PITA for shell scripts (which really get used for more than they should). Escaping perfectly is damned tricky.

    Good thing we have better languages that have strongly typed parameters.

    PS [01:36:30] C:\Users\Arnavion>function Run-Stuff ([string] $name, [string[]] $parameters) { Write-Host $name; Write-Host $parameters; Write-Host $parameters.Length; & $name $parameters }
    PS [01:37:00] C:\Users\Arnavion>Run-Stuff 'C:\Program Files (x86)\Notepad++\notepad++.exe' 'foo.txt', 'bar.txt'
    C:\Program Files (x86)\Notepad++\notepad++.exe
    foo.txt bar.txt
    2

    PS [01:37:30] C:\Users\Arnavion>$someProgramNameThatMightContainSpaces = 'C:\Program Files (x86)\Notepad++\notepad++.exe'
    PS [01:37:42] C:\Users\Arnavion>Run-Stuff $someProgramNameThatMightContainSpaces 'foo.txt', 'bar.txt'  # Look Ma, I don't need no escapes
    C:\Program Files (x86)\Notepad++\notepad++.exe
    foo.txt bar.txt
    2
    

    Too bad the "underlying runtime" dependency means Lunitards would rather bash it than understand its usefulness.



  • @anonymous235 said:

    Error: file can't be deleted because it's currently opened in another process. Good luck finding out which one!

    I used unlocker in the past. I wasn't bothered which process had the lock, just that I wanted to remove the file.

    I'm also struggling to understand what a "read lock" is - how does this differ to a "write lock"...?

     


Log in to reply