Save As dialog file saving/renaming bug?

[JV]

On Windows 98 I got used to using the Save As dialog to rename files I
wanted to update without overwriting. In Windows XP (up-to-date SP2) I can
no longer do that, because there's a bug (feature?) in that dialog.

Renaming a file in the file list of the Save As dialog will update the
"saving target" file name without updating the dialog's file name textbox.

For example:

(1) Open Notepad, enter any text and save the file anywhere as
"renamebug.txt".

(2) Now while the file is still open in Notepad (or after closing and
re-opening, it doesn't matter), choose "Save As..." from the File menu.
Navigate to the folder you saved "renamebug.txt" in in the dialog's file
list box if necessary, right-click "renamebug.txt", choose rename and
rename the file to "renamefeature.txt" (selecting the file and then
clicking it also lets you rename and has the same effect in regards to
this bug).

At this point, your text file has been renamed to "renamefeature.txt" and
it is visible as such in the dialog's file list box. At the same time, the
dialog's text box marked "File name" still has the text "renamebug.txt" in
it.

(3) Now click the Save button...

(4) Behold the bug. You get a warning dialog box saying:
"C:\Path\to\renamefeature.txt already exists. Do you want to replace it?",
even though the file name you thought you were saving as was
"renamebug.txt"!

What I would expect to happen instead is one of the following two cases:
1. After renaming the file to "renamefeature.txt" (step 2 above), the
"File name" text box remains unchanged and upon hitting the Save button
the file is saved as "renamebug.txt" without any warning. This is what
happens in Windows 98.
2. After renaming my file to "renamefeature.txt" (step 2 above), the "File
name" text box updates accordingly and upon hitting the Save button you
get a warning.

This happens with any files or file names involved, in any application
using the standard Windows Save As dialog control, using every
mouse/keyboard-action variation I can think of to go through the steps, on
several different computers running Dutch or English copies of Windows XP
SP2 with the latest Windows Update updates.

A way to quickly circumvent the problem is to add a space in the text box
at the end of the file name before saving. This seems to update the
"target file name" back to the actual contents of the text box and saves
the file with the desired file name (the space typed in at the end is
discarded).

Is this behavior intentional? Can other people reproduce this? Have other
people actually had problems with this before, or am I the only one? Is
this an actual bug in a Windows component (comdlg32.dll?) or could there
be something else interfering that causes this unexpected behavior?

Thanks in advance,

JV

 

[JV]

Anyone?

On Windows 98 I got used to using the Save As dialog to rename files I
wanted to update without overwriting. In Windows XP (up-to-date SP2) I
can no longer do that, because there's a bug (feature?) in that dialog.

Renaming a file in the file list of the Save As dialog will update the
"saving target" file name without updating the dialog's file name
textbox.

For example:

(1) Open Notepad, enter any text and save the file anywhere as
"renamebug.txt".

(2) Now while the file is still open in Notepad (or after closing and
re-opening, it doesn't matter), choose "Save As..." from the File menu.
Navigate to the folder you saved "renamebug.txt" in in the dialog's file
list box if necessary, right-click "renamebug.txt", choose rename and
rename the file to "renamefeature.txt" (selecting the file and then
clicking it also lets you rename and has the same effect in regards to
this bug).

At this point, your text file has been renamed to "renamefeature.txt"
and it is visible as such in the dialog's file list box. At the same
time, the dialog's text box marked "File name" still has the text
"renamebug.txt" in it.

(3) Now click the Save button...

(4) Behold the bug. You get a warning dialog box saying:
"C:\Path\to\renamefeature.txt already exists. Do you want to replace
it?", even though the file name you thought you were saving as was
"renamebug.txt"!

What I would expect to happen instead is one of the following two cases:
1. After renaming the file to "renamefeature.txt" (step 2 above), the
"File name" text box remains unchanged and upon hitting the Save button
the file is saved as "renamebug.txt" without any warning. This is what
happens in Windows 98.
2. After renaming my file to "renamefeature.txt" (step 2 above), the
"File name" text box updates accordingly and upon hitting the Save
button you get a warning.

This happens with any files or file names involved, in any application
using the standard Windows Save As dialog control, using every
mouse/keyboard-action variation I can think of to go through the steps,
on several different computers running Dutch or English copies of
Windows XP SP2 with the latest Windows Update updates.

A way to quickly circumvent the problem is to add a space in the text
box at the end of the file name before saving. This seems to update the
"target file name" back to the actual contents of the text box and saves
the file with the desired file name (the space typed in at the end is
discarded).

Is this behavior intentional? Can other people reproduce this? Have
other people actually had problems with this before, or am I the only
one? Is this an actual bug in a Windows component (comdlg32.dll?) or
could there be something else interfering that causes this unexpected
behavior?

Thanks in advance,

JV

 

[Pegasus \(MVP\)]

On Windows 98 I got used to using the Save As dialog to rename files I
wanted to update without overwriting. In Windows XP (up-to-date SP2) I can
no longer do that, because there's a bug (feature?) in that dialog.

Renaming a file in the file list of the Save As dialog will update the
"saving target" file name without updating the dialog's file name textbox.

For example:

(1) Open Notepad, enter any text and save the file anywhere as
"renamebug.txt".

(2) Now while the file is still open in Notepad (or after closing and
re-opening, it doesn't matter), choose "Save As..." from the File menu.
Navigate to the folder you saved "renamebug.txt" in in the dialog's file
list box if necessary, right-click "renamebug.txt", choose rename and
rename the file to "renamefeature.txt" (selecting the file and then
clicking it also lets you rename and has the same effect in regards to
this bug).

At this point, your text file has been renamed to "renamefeature.txt" and
it is visible as such in the dialog's file list box. At the same time, the
dialog's text box marked "File name" still has the text "renamebug.txt" in
it.

(3) Now click the Save button...

(4) Behold the bug. You get a warning dialog box saying:
"C:\Path\to\renamefeature.txt already exists. Do you want to replace it?",
even though the file name you thought you were saving as was
"renamebug.txt"!

What I would expect to happen instead is one of the following two cases:
1. After renaming the file to "renamefeature.txt" (step 2 above), the
"File name" text box remains unchanged and upon hitting the Save button
the file is saved as "renamebug.txt" without any warning. This is what
happens in Windows 98.
2. After renaming my file to "renamefeature.txt" (step 2 above), the "File
name" text box updates accordingly and upon hitting the Save button you
get a warning.

This happens with any files or file names involved, in any application
using the standard Windows Save As dialog control, using every
mouse/keyboard-action variation I can think of to go through the steps, on
several different computers running Dutch or English copies of Windows XP
SP2 with the latest Windows Update updates.

A way to quickly circumvent the problem is to add a space in the text box
at the end of the file name before saving. This seems to update the
"target file name" back to the actual contents of the text box and saves
the file with the desired file name (the space typed in at the end is
discarded).

Is this behavior intentional? Can other people reproduce this? Have other
people actually had problems with this before, or am I the only one? Is
this an actual bug in a Windows component (comdlg32.dll?) or could there
be something else interfering that causes this unexpected behavior?

Thanks in advance,

JV

I can reproduce the phenomenon you observe but at the same
time I think you're going out of your way to create a situation
that goes contrary to sound file managment. You see, you're
renaming a file that is currently open. If you try your trick with
an MS Word document then you will immediately see what
I mean. To avoid this issue, you should change your habits
and do this:

- Either use "Save as",
- Or use "Save", then use "Rename" after the document is closed.

In other words, I don't think it is a good idea trying to rename
an open document.

 

[Bob I]

If you try this with office file you aren't allowed to rename them.
Basically you shouldn't be trying to rename files you have open.

 

[JV]

I can reproduce the phenomenon you observe but at the same
time I think you're going out of your way to create a situation
that goes contrary to sound file managment. You see, you're
renaming a file that is currently open. If you try your trick with
an MS Word document then you will immediately see what
I mean.

I don't think I'm going out of my way at all. The reason I do it in the
first place is because it's a quick and convenient way to make a backup of
a file I'm working on. It's an application's responsibility to make sure
that I can't rename or otherwise modify a file if necessary by locking it.
And if a file is locked, renaming isn't possible so this issue doesn't
come up. I assume that's what happens with Office as Bob said (I don't
have Office myself), so the point is moot.

While it may not be a good idea to rename an open document, there are many
other ways to do that anyway. I could simply go into Explorer and rename,
or even delete, an open file. Or I might open a file in a second
application and edit and save it there. In fact, some applications
specifically allow and benefit from that sort of behavior. But none of
those methods trigger this bug, because it's something specific to the
Save As dialog.

So I don't think any of that is really the issue. The simple problem is
that the Save As dialog doesn't do what it says it will do.