Menu

N++ crashing due to folder privs

Miamidot
2008-09-08
2012-11-13
  • Miamidot

    Miamidot - 2008-09-08

    I think it is  time to admit that having N++ locking the parent folder of a file being edited is not a good practice.

    This is because on vista, N++ crashes when you try to view a file whose parent folder does not give the user permission anything but read. These are examples:

    1. N++ cannot be used to read a text file on a CD.

    2. If you have a NTFS flash or portable drive where files are created on your office computer by user A, when you bring it to your laptop, N++ crashes trying to lock the folder on that drive. The reason is user A does not exist on the laptop.

    3. Finally, the old problem of a folder being locked from being deleted or renamed even when all the files are closed.

    The remedy is, when the last file has been closed, N++ should lock on to the user's home directory rather than the last opened directory.

    I know you are very resistant to making this change but N++ to me now is like microsoft windows has been to many of us. We had been very dependent on Windows. We were addicted to it and cannot change because there is no competitor who could do it better. And then, when we asked Microsoft to change some features, they all fall on deaf ears.

    Similarly, N++ is so good and I'm so dependent on it that whenever I try to use another editor, I just have to using N++. It's just this stinkin lousy problem of locking a directory that you are insistent on not changing.

    If you could just make this tiny weeny change, I would be so ecstatically happy and I would be in editor paradise. Because right now, I have to takeover ownership of a folder on a laptop. And then when I return to the office computer, I have to retakeover the ownership - just to be able to read the files. Alternatively, I have to bring up an alternate but mostly dysfunctional editor just to view the file.

    I guess many users who complained of N++ crashing do not realise this is the reason.

     
    • Miamidot

      Miamidot - 2008-09-11

      Let there be two computers that are not related through common/network user accounts: A & B. B should be a Vista system.

      Let there be a USB drive formatted in NTFS.

      Attach usb drive to A and create a folder "Fish" on the USB drive. Using user "halibut", create some text files in Fish folder. Give full control to user halibut for all the files. Give only read/modify to everyone else.

      Attach usb drive to B using user "salmon". Navigate to folder Fish using File Explorer. Right click on any text file (say, hello.txt) in that folder and choose "Edit with Notepad++".

      Voila! N++ crashes.

      Right click on a text file hello.txt to copy it to the same folder and name it hello-copy.txt. Right click on the hello-copy.txt, and choose "Edit with Notepad++", N++ opens hello-copy.txt peacefully without crashing.

      Right click to inspect properties of both files on computer B. You will see that hello.txt is owned by an "unknown account", while hello-copy.txt is owned by salmon@B.

       
    • Don HO

      Don HO - 2008-09-08

      Notepad++ does not lock the directory, system does it.
      Notepad++ just set the current working directory, that makes system lock the set directory.

      A solution to not use "SetCurrentDirectory" function call but keeping tracking the last operation directory will be in next release.

      However, this problem mentioned above will never make crash Notepad++, even under vista.
      Could you give us more detail in order to reproduce the crash?

      Don