I've noticed an issue with both N++ 3.2 and with 3.3 in that if you open a file and then close it, it doesn't relinquish the file handle.
If the file happens to be on a USB thumbdrive or whatever, it can't be properly unmounted until N++ is closed. If it's in a folder, the folder can't be renamed or deleted until N++ is closed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
N++ should also relinquish that "directory/folder" handle as well, especially if there are no files open from that folder. All other editing programs (even Photoshop) correctly do this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess a fix would be doing a SetCurrentDirectory() to the active file tab once a file is closed (if not already doing this), and when closing the last file, SetCurrentDirectory() to the install folder of NP++
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The full solution is to intercept messages asking for drive removal and switch defaults away from any that come through. That seems extreme for an editor.
The proposed solution will only work if Notepad++ sets the current folder to a known safe folder when no files are up then set it back to the previous current folder when the next file dialog comes up. Not doing that will cause a lot of complaints when people close all files then open another one to find that their default folder has been changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What if N++ checked to see if the drive on which the current directory is on is removable and if it is...then switch.
Or at least give an option for the user to change the behavior of the current directory setting.
M$ word seems to do it correctly and if that folder doesn't exist, then it will go to "My Documents".
Actually, I don't see why "SetCurrentDir" has to even be set. A string variable with the path can be used to store and the current directory it is set to is something that is static (%WINDIR% or parent folder where N++ is) and then, when a file dialog function is used, it checks to see if the path exists...then switches to it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fix: change CWD on fileclose as I already proposed, keep a global string with "last active directory", and fill the win32 file-open structure from this string before calling the openfiledialog.
Presto, no more locked folders, but last folder will be remembered even user closes all files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's because system locks the directory due to the SteCurrentDirectory() function call in Notepad++.
There're 2 modes for setting the current directory in Notepad++, which change the behaviour of open/save file dialog (an option in the Preference dialog):
1. Remember the last operation directory (so the current directory is set on the last open/save directory).
2. The current directory follows the current document (so if you switch to another document, the current document will be set on the directory where the current document is located).
If you set the behaviour in question in mode 1, when you close the current file, then try to delete the directory where the closed file located, it will fail (since the directory is always set as current directory). To remedy your problem, set this behaviour in mode 2.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've noticed an issue with both N++ 3.2 and with 3.3 in that if you open a file and then close it, it doesn't relinquish the file handle.
If the file happens to be on a USB thumbdrive or whatever, it can't be properly unmounted until N++ is closed. If it's in a folder, the folder can't be renamed or deleted until N++ is closed.
It's not about file handle : all the file handles are closed properly by Notepad++.
The problem you have is because the directory of opened file is set as current directory of Notepad++ (so the folder is locked by Windows).
Don
N++ should also relinquish that "directory/folder" handle as well, especially if there are no files open from that folder. All other editing programs (even Photoshop) correctly do this.
I guess a fix would be doing a SetCurrentDirectory() to the active file tab once a file is closed (if not already doing this), and when closing the last file, SetCurrentDirectory() to the install folder of NP++
What about changing the CWD to a path that it can't/won't be renamed or deleted, %WINNT% or %TEMP%?
Regards,
Patrick.
The full solution is to intercept messages asking for drive removal and switch defaults away from any that come through. That seems extreme for an editor.
The proposed solution will only work if Notepad++ sets the current folder to a known safe folder when no files are up then set it back to the previous current folder when the next file dialog comes up. Not doing that will cause a lot of complaints when people close all files then open another one to find that their default folder has been changed.
What if N++ checked to see if the drive on which the current directory is on is removable and if it is...then switch.
Or at least give an option for the user to change the behavior of the current directory setting.
M$ word seems to do it correctly and if that folder doesn't exist, then it will go to "My Documents".
Actually, I don't see why "SetCurrentDir" has to even be set. A string variable with the path can be used to store and the current directory it is set to is something that is static (%WINDIR% or parent folder where N++ is) and then, when a file dialog function is used, it checks to see if the path exists...then switches to it.
Fix: change CWD on fileclose as I already proposed, keep a global string with "last active directory", and fill the win32 file-open structure from this string before calling the openfiledialog.
Presto, no more locked folders, but last folder will be remembered even user closes all files.
cool.
fixed without compromising the functionality that ppl wanted.
who says you can't have your cake and eat it too?
o....which official version will have the fix?
it'll be in v3.5
Don
Is there any progress with this? I have version 4.1.2 installed and this behavior is still present.
There is an open bug report about it
[ 1805869 ] Cannot delete directory that contained deleted file
http://sourceforge.net/tracker/index.php?func=detail&aid=1805869&group_id=95717&atid=612382
It's not a bug but a behaviour issue.
It's because system locks the directory due to the SteCurrentDirectory() function call in Notepad++.
There're 2 modes for setting the current directory in Notepad++, which change the behaviour of open/save file dialog (an option in the Preference dialog):
1. Remember the last operation directory (so the current directory is set on the last open/save directory).
2. The current directory follows the current document (so if you switch to another document, the current document will be set on the directory where the current document is located).
If you set the behaviour in question in mode 1, when you close the current file, then try to delete the directory where the closed file located, it will fail (since the directory is always set as current directory). To remedy your problem, set this behaviour in mode 2.
Don
cool....can't wait.....
so when's v3.5 going to be out? lol