Windows should increment file names

[Char Jackson]

It seems like when I click on a file the other entity remains selected,
in view or not, and this is confusing at best...which is why it sounds
like what I'm seeing, but maybe it isn't quite that...

Yes, we did discuss this (or something similar) with respect to
Libraries, and later I posted that I had seen it (or something similar)
happen outside of any Library context.

For me the upshot of it is that in the heat of battle, my perceptions
may be (and surely *are*) confused, and I haven't yet managed to be in
a situation where I have (or take) a few seconds to try to see what is
actually happening. I.e., I react too quickly and thereby lose the
opportunity to investigate...

So I'll at least try to watch what is happening so I can avoid trouble,
and maybe I'll even get a clear idea of what is happening. But until
then, I'd better avoid sounding definitive.

And now you also have an idea why I inserted the parenthetical "or
something similar" above

Sounds good. Keep us in the loop. Inquiring minds want to know.

 

[VanguardLH]

VanguardLH wrote:

Metspitzer wrote:

Windows picks a name for an untitled document. If the untilled
document exists already, why not add a 1 to the filename?

Windows does not pick names for documents. Your APPLICATION does
that but you never mentioned the application you are using.

When you load your unidentified application to create a document,
it's not likely it will consume gobs of memory in preparation for
your work on the document since it won't know the size of the
document. Your application is going to create a [sometimes
temporary] file which can be expanded as needed as you add more to
the document.

So what *application* are you using to create a new document?

Note pad
Word pad
Paint

When you open those programs, they don't create a temporary file. What
you put into the empty doc is in a buffer. You can see this by using
Nirsoft's OpenFilesViewer to see what processes have opened a file
handle. When you load Notepad, Wordpad, or Paint (without specifying a
file so you end up with a new doc when they load), they don't open a
file which assigns a handle to that object. Not until you choose to
Save [As] for that document do filenames come into play.

Some applications may create a temporary file and it's up to them to
create differently named temp files if multiple new docs are opened in
that same application and it's not using a buffer.

Those are a few

If the application is loaded without specifying a file to open, why
would there be any filename conflict when you go to save the document?
When you load the application without specifying a file, you get a blank
(untitled) document in the application. Then when you go to save your
changes, YOU will have to specify a filename. The document is untitled.
It doesn't yet have a filename associated with it. YOU had to give it a
name.

When saving the unassociated buffer into a file and after YOU specify
the filename (since it didn't have one yet), and if you specify a
filename for an already existing file, you get prompted that the file
already exists. You can choose to cancel (to pick a different path and
filename) or to overwrite the existing file. If the file already exists
and after getting the prompt that it already exists when you try to save
into the same path and filename, and if you don't want to overwrite,
then cancel and pick a different filename; for example, append "1" to
the filename that you wanted.

You open Notepad, Wordpad, or Paint. You didn't specify a filename so
the app creates a new empty doc. There is no filename conflict because
the new doc doesn't have a filename associated with it yet. Then when
you go to save the new document is when YOU are asked to specify a
filename. It's up to you what filename you give the new doc.

Maybe what you're asking is why an incremental number isn't appended
when you choose to Save As a document. Well, the app prompts YOU for
the target filename. If there's a conflict with an existing file then
YOU specify a different filename. Save [As] is not a file versioning
feature to keep appending numbers onto filenames as you repeatedly save
updated copies of a document. It uses whatever filename you specify.

Where was Windows involved in picking the filenames for Save [As] on a
new or old document?

Windows does furnish a filename if you have made a document from
scratch using Wordpad, for example. I sometimes open wordpad and jot
down a note or two. This happened yesterday when I was trying to
contact customer support. I only needed to jot down the support
number and the person's name that took the call.

The application has a default filename when you have loading that
application without specifying a filename (to open). You load the app,
you edit the doc, and when you save from that app then the app picks a
default name. The app has NOT even checked if a file by that same
filename already exists (that's what you are probably assuming). The
app doesn't know WHERE you are going to do the save until you click the
Save button at which point you have selected (by navigation or accepting
the defaults) the path and filename. Only when you press the Save
button does the app then check if it can save in that path under that
filename without a conflict. That's when it checks at the destination.

There is Browse dialog for selecting a path. That doesn't check for
conflict in filenaming since the other half of the criteria is the
filename but the Browse dialog won't know that is that actual filename
you will use. Only when you click on Save does the Browse dialog have
all the info - path and filename - to then check for conflict.

The apps don't perform file versioning either by retaining old copies of
a file under a backup somewhere or by appending numbers to the old or
new files. They just attempt to do the save that you specified. The
save will either not conflict (no existing file in the selected path has
the same name) or there is a conflict (an existing file in the selected
path has the same name). The only recourse the Browse dialog affords to
you is to change the save criteria (which includes both path and name).

You want the apps to do file versioning. They don't do that. Adding
file versioning to Windows requires using something akin to a background
always-active backup program that will retain up to some specified
maximum number of old versions for a file. However, you will need to
use that 3rd party file versioning utility to retrieve an old version of
a file.

What I do is, when I am finished making notes, just click to close the
window. Windows asks for a filename. It defaults to Document.rtf so
I just save the file as Document.rtf. If I have another occasion to
take a note or two I repeat the process. This time when I save it
Windows defaults to Document.rtf again. I get an error that the
filename already exists. I can rename it or replace it. It should
automatically pick Document(2).rtf

Yep, each *application* has its own and different default filename (but
sometimes not, as in Notepad defaults to *.txt which is obviously an
illegal filename). The application is not checking the file system
until after you click on the Save button. Only then will it know for
sure what path and name you want to use and only then will it merely
check for conflict or not. If it didn't check for conflict, users would
end up stepping atop of files they did not intend to do so. The Browse
dialog doesn't have to do the warning. It's a common safety measure to
show a prompt in case of conflict. Similarly, if you make changes to a
doc (not if you just view it) and exit the application, another safety
measure is to prompt if you want to save your changes.

The app is merely doing what you told it to do. You specified the path
and name. When you click the Save button only then does the app know
for sure what you want to use and only then does it check for conflict
or not. Again, the apps don't do file versioning. I don't recall
anyone, and especially no company, clamoring for file versioning to be
implemented within an app. Just imagine the problems with tracking
files if every app employed its own different file versioning scheme.
File versioning is something done at a lower level than at the apps.

Adding file versioning via a service or background process that is
monitoring file replacement will still not alter the behavior of the
Browse dialog in applications. You aren't changing their code. The
apps will still not check for conflict until you click the Save button.
If you use a new filename, like appending a number, then you are not
stepping atop an existing file so file versioning is not relevant. You
are saving to a new file. If, however, you get the conflict alert
prompt from the app and chose to override the file is when the file
versioning software kicks in to save the old instance of the file you
just overwrote.

In the video below, you are using Windows Explorer to access the old
versions stored in System Restore snapshots. The apps don't do the file
versioning. The OS (well, the backup or snapshot program) is saving the
old instances of an overwritten file. You'll see in the video that you
use Windows Explorer to access the file versioning support in the OS.

(at the 0:40 timemark on how to select an old overwritten version)
(at the 4:00 timemark on how to configure Backup to do file versioning)

(hey, that wasn't my choice for a desktop background)
(at 2:00 timemark, shows Previous Versions property tab on a folder)
(use the Previous Versions content menu entry for an existing file)

However, file versioning will retain only so many copies of old
instances of a file (that was repeatedly overwritten). If the app is
digging into System Restore then you only get the granularity afforded
by that function to find old versions of a file and only as far back as
System Restore retains its oldest snapshot. In UNIX, I believe (or
maybe it was Exec for the Unisys 1100 mainframes), you can enable file
versioning as part of the OS and also specify how many old versions you
can keep. The default was 3 but could be set up to 64. In Windows 7,
you use the System Restore service to keep old copies of an overwritten
file at the granularity afforded by the System Restore service.

However, although file versioning lets you access old instances of
overwritten files, you still only get one copy of the file you can
access. Consider it like a Rolodex card file where you can spin through
all the cards but you only read one at a time. These old versions do
NOT have some number appended to them. They all have the SAME filename.
Just like any backup program, you select an old instance to restore and
it steps atop the existing available copy of that file.

The applications don't do file versioning. They can't because they
won't know what different scheme might be employed by some other
application. File versioning is done in the OS (by some service or
background process that monitors file operations). File versioning
doesn't append numbers onto files but just keeps old copies of the file
and under the same name.

You could use a 3rd party backup, synchronization, or snapshot program
that is set to very small update intervals, like 5 minutes, to do
incremental backups but that will miss any changes to files between the
backups. For a real file versioning setup, you need to use a
kernel-mode driver that intercepts all file operations so the driver can
see all the file I/O requests as they occur, not poll for changes
sometime later. When the file gets changed (after releasing the handle
on the file) then the driver would save a backup copy of the old
instance before allowing saving of the new changes. The whole old file
isn't changed, just the incremental changes made to the file.

You want the apps to do the file versioning. Apps are written by
different authors so each app would employ a different file versioning
scheme. That means inconsistent methods. So apps don't do file
versioning. Something else does that either through backups and the
granularity of how often they save or through on-access methods (e.g.,
driver monitoring of system calls for file I/O) to ensure all old
instances are retained. Apps don't work at those levels.

 

[VanguardLH]

I am not sure (make that "I have no idea") how *I* have done it, but
there has been more than one occasion where the file name or directory
name which I thought I selected, and which is highlighted, is *not* the
one that the application (usually Windows Explorer) thinks is selected.
These days, I try to look closely with my beady eyes before accepting
anything :-(

The last time was two or three days ago, and it was not me but the
person I was watching & "helping" who experienced that.

I think it happened in Windows Live Mail, but I'm not sure my memory is
clear (because of the confusion of that session).

I suspect that comes from you right-clicking on a file (which makes it
look highlighted) and then selecting an action from the context menu
versus you left-clicking on the file to actually select it.
Right-clicking on a file doesn't actually select the file. I've done
that several times. I right-click on a file, thought it was selected,
and then committed an action but it was for the actual selected file.
So to be sure that I select a file, I left-click on it before
right-clicking on it - but that's only in some applications. It seems
to be a defect in the Browse dialog or tree list within an application
where right-clicking on a file doesn't not also mean it is selected.

 

[VanguardLH]

VanguardLH wrote:

Metspitzer wrote:

Windows picks a name for an untitled document. If the untilled
document exists already, why not add a 1 to the filename?

Windows does not pick names for documents. Your APPLICATION does
that but you never mentioned the application you are using.

When you load your unidentified application to create a document,
it's not likely it will consume gobs of memory in preparation for
your work on the document since it won't know the size of the
document. Your application is going to create a [sometimes
temporary] file which can be expanded as needed as you add more to
the document.

So what *application* are you using to create a new document?

That middle paragraph is oddly out of place. Does the size of a
document play a role in how its default name is generated?

What I meant is Windows isn't going to allocate all of available memory
for a file space since it won't know how big will be the file. It will
load the application into memory (a portion of it) and the application
might allocate a buffer in which it loads a portion of the file.
Whether temporary or the target file, the app is going to create a file
for the new document, not Windows.

Fair enough, but still 100% unrelated to the OP's question about
default filenames.

Then why did YOU ask your question? You asked, I answered, and now it's
unrelated? No, it wasn't unrelated to YOUR question in your subthread.
Was my prior reply unrelated? No, because it says the app might create
a memory buffer for the document but the app is still the culprit that
creates a file.

 

[Bob Hatch]

Windows does furnish a filename if you have made a document from
scratch using Wordpad, for example. I sometimes open wordpad and jot
down a note or two. This happened yesterday when I was trying to
contact customer support. I only needed to jot down the support
number and the person's name that took the call.

Why not use the "sticky notes" app. That's what I do, and I don't have
to save a file, or open a program.

 

[Metspitzer]

Metspitzer wrote:

VanguardLH wrote:

Metspitzer wrote:

Windows picks a name for an untitled document. If the untilled
document exists already, why not add a 1 to the filename?

Windows does not pick names for documents. Your APPLICATION does
that but you never mentioned the application you are using.

When you load your unidentified application to create a document,
it's not likely it will consume gobs of memory in preparation for
your work on the document since it won't know the size of the
document. Your application is going to create a [sometimes
temporary] file which can be expanded as needed as you add more to
the document.

So what *application* are you using to create a new document?

Note pad
Word pad
Paint

When you open those programs, they don't create a temporary file. What
you put into the empty doc is in a buffer. You can see this by using
Nirsoft's OpenFilesViewer to see what processes have opened a file
handle. When you load Notepad, Wordpad, or Paint (without specifying a
file so you end up with a new doc when they load), they don't open a
file which assigns a handle to that object. Not until you choose to
Save [As] for that document do filenames come into play.

Some applications may create a temporary file and it's up to them to
create differently named temp files if multiple new docs are opened in
that same application and it's not using a buffer.

Those are a few

If the application is loaded without specifying a file to open, why
would there be any filename conflict when you go to save the document?
When you load the application without specifying a file, you get a blank
(untitled) document in the application. Then when you go to save your
changes, YOU will have to specify a filename. The document is untitled.
It doesn't yet have a filename associated with it. YOU had to give it a
name.

When saving the unassociated buffer into a file and after YOU specify
the filename (since it didn't have one yet), and if you specify a
filename for an already existing file, you get prompted that the file
already exists. You can choose to cancel (to pick a different path and
filename) or to overwrite the existing file. If the file already exists
and after getting the prompt that it already exists when you try to save
into the same path and filename, and if you don't want to overwrite,
then cancel and pick a different filename; for example, append "1" to
the filename that you wanted.

You open Notepad, Wordpad, or Paint. You didn't specify a filename so
the app creates a new empty doc. There is no filename conflict because
the new doc doesn't have a filename associated with it yet. Then when
you go to save the new document is when YOU are asked to specify a
filename. It's up to you what filename you give the new doc.

Maybe what you're asking is why an incremental number isn't appended
when you choose to Save As a document. Well, the app prompts YOU for
the target filename. If there's a conflict with an existing file then
YOU specify a different filename. Save [As] is not a file versioning
feature to keep appending numbers onto filenames as you repeatedly save
updated copies of a document. It uses whatever filename you specify.

Where was Windows involved in picking the filenames for Save [As] on a
new or old document?

Windows does furnish a filename if you have made a document from
scratch using Wordpad, for example. I sometimes open wordpad and jot
down a note or two. This happened yesterday when I was trying to
contact customer support. I only needed to jot down the support
number and the person's name that took the call.

The application has a default filename when you have loading that
application without specifying a filename (to open). You load the app,
you edit the doc, and when you save from that app then the app picks a
default name. The app has NOT even checked if a file by that same
filename already exists (that's what you are probably assuming). The
app doesn't know WHERE you are going to do the save until you click the
Save button at which point you have selected (by navigation or accepting
the defaults) the path and filename. Only when you press the Save
button does the app then check if it can save in that path under that
filename without a conflict. That's when it checks at the destination.

There is Browse dialog for selecting a path. That doesn't check for
conflict in filenaming since the other half of the criteria is the
filename but the Browse dialog won't know that is that actual filename
you will use. Only when you click on Save does the Browse dialog have
all the info - path and filename - to then check for conflict.

The apps don't perform file versioning either by retaining old copies of
a file under a backup somewhere or by appending numbers to the old or
new files. They just attempt to do the save that you specified. The
save will either not conflict (no existing file in the selected path has
the same name) or there is a conflict (an existing file in the selected
path has the same name). The only recourse the Browse dialog affords to
you is to change the save criteria (which includes both path and name).

You want the apps to do file versioning. They don't do that. Adding
file versioning to Windows requires using something akin to a background
always-active backup program that will retain up to some specified
maximum number of old versions for a file. However, you will need to
use that 3rd party file versioning utility to retrieve an old version of
a file.

What I do is, when I am finished making notes, just click to close the
window. Windows asks for a filename. It defaults to Document.rtf so
I just save the file as Document.rtf. If I have another occasion to
take a note or two I repeat the process. This time when I save it
Windows defaults to Document.rtf again. I get an error that the
filename already exists. I can rename it or replace it. It should
automatically pick Document(2).rtf

Yep, each *application* has its own and different default filename (but
sometimes not, as in Notepad defaults to *.txt which is obviously an
illegal filename). The application is not checking the file system
until after you click on the Save button.

Yeah. I know it is not. I was just suggesting it should. Some
programs seem to be able to do it without a problem.

Only then will it know for
sure what path and name you want to use and only then will it merely
check for conflict or not. If it didn't check for conflict, users would
end up stepping atop of files they did not intend to do so. The Browse
dialog doesn't have to do the warning. It's a common safety measure to
show a prompt in case of conflict. Similarly, if you make changes to a
doc (not if you just view it) and exit the application, another safety
measure is to prompt if you want to save your changes.

The app is merely doing what you told it to do. You specified the path
and name. When you click the Save button only then does the app know
for sure what you want to use and only then does it check for conflict
or not. Again, the apps don't do file versioning. I don't recall
anyone, and especially no company, clamoring for file versioning to be
implemented within an app. Just imagine the problems with tracking
files if every app employed its own different file versioning scheme.
File versioning is something done at a lower level than at the apps.

Adding file versioning via a service or background process that is
monitoring file replacement will still not alter the behavior of the
Browse dialog in applications. You aren't changing their code. The
apps will still not check for conflict until you click the Save button.
If you use a new filename, like appending a number, then you are not
stepping atop an existing file so file versioning is not relevant. You
are saving to a new file. If, however, you get the conflict alert
prompt from the app and chose to override the file is when the file
versioning software kicks in to save the old instance of the file you
just overwrote.

In the video below, you are using Windows Explorer to access the old
versions stored in System Restore snapshots. The apps don't do the file
versioning. The OS (well, the backup or snapshot program) is saving the
old instances of an overwritten file. You'll see in the video that you
use Windows Explorer to access the file versioning support in the OS.

(at the 0:40 timemark on how to select an old overwritten version)
(at the 4:00 timemark on how to configure Backup to do file versioning)

(hey, that wasn't my choice for a desktop background)
(at 2:00 timemark, shows Previous Versions property tab on a folder)
(use the Previous Versions content menu entry for an existing file)

However, file versioning will retain only so many copies of old
instances of a file (that was repeatedly overwritten). If the app is
digging into System Restore then you only get the granularity afforded
by that function to find old versions of a file and only as far back as
System Restore retains its oldest snapshot. In UNIX, I believe (or
maybe it was Exec for the Unisys 1100 mainframes), you can enable file
versioning as part of the OS and also specify how many old versions you
can keep. The default was 3 but could be set up to 64. In Windows 7,
you use the System Restore service to keep old copies of an overwritten
file at the granularity afforded by the System Restore service.

However, although file versioning lets you access old instances of
overwritten files, you still only get one copy of the file you can
access. Consider it like a Rolodex card file where you can spin through
all the cards but you only read one at a time. These old versions do
NOT have some number appended to them. They all have the SAME filename.
Just like any backup program, you select an old instance to restore and
it steps atop the existing available copy of that file.

The applications don't do file versioning. They can't because they
won't know what different scheme might be employed by some other
application. File versioning is done in the OS (by some service or
background process that monitors file operations). File versioning
doesn't append numbers onto files but just keeps old copies of the file
and under the same name.

You could use a 3rd party backup, synchronization, or snapshot program
that is set to very small update intervals, like 5 minutes, to do
incremental backups but that will miss any changes to files between the
backups. For a real file versioning setup, you need to use a
kernel-mode driver that intercepts all file operations so the driver can
see all the file I/O requests as they occur, not poll for changes
sometime later. When the file gets changed (after releasing the handle
on the file) then the driver would save a backup copy of the old
instance before allowing saving of the new changes. The whole old file
isn't changed, just the incremental changes made to the file.

You want the apps to do the file versioning. Apps are written by
different authors so each app would employ a different file versioning
scheme. That means inconsistent methods. So apps don't do file
versioning. Something else does that either through backups and the
granularity of how often they save or through on-access methods (e.g.,
driver monitoring of system calls for file I/O) to ensure all old
instances are retained. Apps don't work at those levels.

Thanks

 

[Metspitzer]

Why not use the "sticky notes" app. That's what I do, and I don't have
to save a file, or open a program.

I will give it a shot.
Thanks

 

[Char Jackson]

I suspect that comes from you right-clicking on a file (which makes it
look highlighted) and then selecting an action from the context menu
versus you left-clicking on the file to actually select it.
Right-clicking on a file doesn't actually select the file. I've done
that several times. I right-click on a file, thought it was selected,
and then committed an action but it was for the actual selected file.
So to be sure that I select a file, I left-click on it before
right-clicking on it - but that's only in some applications. It seems
to be a defect in the Browse dialog or tree list within an application
where right-clicking on a file doesn't not also mean it is selected.

I'm having trouble finding a scenario where right clicking on a file
doesn't select it. I don't have much hope of finding it because most
apps use the common Windows dialogs, so their behavior is necessarily
standardized.

 

[Char Jackson]

Char Jackson wrote:

VanguardLH wrote:

Metspitzer wrote:

Windows picks a name for an untitled document. If the untilled
document exists already, why not add a 1 to the filename?

Windows does not pick names for documents. Your APPLICATION does
that but you never mentioned the application you are using.

When you load your unidentified application to create a document,
it's not likely it will consume gobs of memory in preparation for
your work on the document since it won't know the size of the
document. Your application is going to create a [sometimes
temporary] file which can be expanded as needed as you add more to
the document.

So what *application* are you using to create a new document?

That middle paragraph is oddly out of place. Does the size of a
document play a role in how its default name is generated?

What I meant is Windows isn't going to allocate all of available memory
for a file space since it won't know how big will be the file. It will
load the application into memory (a portion of it) and the application
might allocate a buffer in which it loads a portion of the file.
Whether temporary or the target file, the app is going to create a file
for the new document, not Windows.

Fair enough, but still 100% unrelated to the OP's question about
default filenames.

Then why did YOU ask your question?

I was trying to gently guide you into understanding that your middle
paragraph was 100% unrelated to the OP's question. Instead of picking
up on what I was trying to point out, you blindly forged ahead, still
100% unrelated to the OP's question about file names.

You asked, I answered,

Your answer should have been "No, and I apologize for wandering off on
a tangent", but that's not what happened.

and now it's unrelated?

It was always 100% unrelated. I'm sure you see that now.

No, it wasn't unrelated to YOUR question in your subthread.
Was my prior reply unrelated? No, because it says the app might create
a memory buffer for the document but the app is still the culprit that
creates a file.

You'll probably want to rethink that.

What you did is what is colloquially considered to be a "Microsoft
answer". What that means is that the information you provided was
factually correct, but it had absolutely nothing to do with the
question being asked.

 

[Char Jackson]

Metspitzer wrote:

VanguardLH wrote:

Metspitzer wrote:

Windows picks a name for an untitled document. If the untilled
document exists already, why not add a 1 to the filename?

Windows does not pick names for documents. Your APPLICATION does
that but you never mentioned the application you are using.

When you load your unidentified application to create a document,
it's not likely it will consume gobs of memory in preparation for
your work on the document since it won't know the size of the
document. Your application is going to create a [sometimes
temporary] file which can be expanded as needed as you add more to
the document.

So what *application* are you using to create a new document?

Note pad
Word pad
Paint

When you open those programs, they don't create a temporary file. What
you put into the empty doc is in a buffer. You can see this by using
Nirsoft's OpenFilesViewer to see what processes have opened a file
handle. When you load Notepad, Wordpad, or Paint (without specifying a
file so you end up with a new doc when they load), they don't open a
file which assigns a handle to that object. Not until you choose to
Save [As] for that document do filenames come into play.

Some applications may create a temporary file and it's up to them to
create differently named temp files if multiple new docs are opened in
that same application and it's not using a buffer.

Those are a few

If the application is loaded without specifying a file to open, why
would there be any filename conflict when you go to save the document?
When you load the application without specifying a file, you get a blank
(untitled) document in the application. Then when you go to save your
changes, YOU will have to specify a filename. The document is untitled.
It doesn't yet have a filename associated with it. YOU had to give it a
name.

When saving the unassociated buffer into a file and after YOU specify
the filename (since it didn't have one yet), and if you specify a
filename for an already existing file, you get prompted that the file
already exists. You can choose to cancel (to pick a different path and
filename) or to overwrite the existing file. If the file already exists
and after getting the prompt that it already exists when you try to save
into the same path and filename, and if you don't want to overwrite,
then cancel and pick a different filename; for example, append "1" to
the filename that you wanted.

You open Notepad, Wordpad, or Paint. You didn't specify a filename so
the app creates a new empty doc. There is no filename conflict because
the new doc doesn't have a filename associated with it yet. Then when
you go to save the new document is when YOU are asked to specify a
filename. It's up to you what filename you give the new doc.

Maybe what you're asking is why an incremental number isn't appended
when you choose to Save As a document. Well, the app prompts YOU for
the target filename. If there's a conflict with an existing file then
YOU specify a different filename. Save [As] is not a file versioning
feature to keep appending numbers onto filenames as you repeatedly save
updated copies of a document. It uses whatever filename you specify.

Where was Windows involved in picking the filenames for Save [As] on a
new or old document?

Windows does furnish a filename if you have made a document from
scratch using Wordpad, for example. I sometimes open wordpad and jot
down a note or two. This happened yesterday when I was trying to
contact customer support. I only needed to jot down the support
number and the person's name that took the call.

The application has a default filename when you have loading that
application without specifying a filename (to open). You load the app,
you edit the doc, and when you save from that app then the app picks a
default name. The app has NOT even checked if a file by that same
filename already exists (that's what you are probably assuming). The
app doesn't know WHERE you are going to do the save until you click the
Save button at which point you have selected (by navigation or accepting
the defaults) the path and filename. Only when you press the Save
button does the app then check if it can save in that path under that
filename without a conflict. That's when it checks at the destination.

There is Browse dialog for selecting a path. That doesn't check for
conflict in filenaming since the other half of the criteria is the
filename but the Browse dialog won't know that is that actual filename
you will use. Only when you click on Save does the Browse dialog have
all the info - path and filename - to then check for conflict.

The apps don't perform file versioning either by retaining old copies of
a file under a backup somewhere or by appending numbers to the old or
new files. They just attempt to do the save that you specified. The
save will either not conflict (no existing file in the selected path has
the same name) or there is a conflict (an existing file in the selected
path has the same name). The only recourse the Browse dialog affords to
you is to change the save criteria (which includes both path and name).

You want the apps to do file versioning. They don't do that. Adding
file versioning to Windows requires using something akin to a background
always-active backup program that will retain up to some specified
maximum number of old versions for a file. However, you will need to
use that 3rd party file versioning utility to retrieve an old version of
a file.

What I do is, when I am finished making notes, just click to close the
window. Windows asks for a filename. It defaults to Document.rtf so
I just save the file as Document.rtf. If I have another occasion to
take a note or two I repeat the process. This time when I save it
Windows defaults to Document.rtf again. I get an error that the
filename already exists. I can rename it or replace it. It should
automatically pick Document(2).rtf

Yep, each *application* has its own and different default filename (but
sometimes not, as in Notepad defaults to *.txt which is obviously an
illegal filename). The application is not checking the file system
until after you click on the Save button. Only then will it know for
sure what path and name you want to use and only then will it merely
check for conflict or not. If it didn't check for conflict, users would
end up stepping atop of files they did not intend to do so. The Browse
dialog doesn't have to do the warning. It's a common safety measure to
show a prompt in case of conflict. Similarly, if you make changes to a
doc (not if you just view it) and exit the application, another safety
measure is to prompt if you want to save your changes.

The app is merely doing what you told it to do. You specified the path
and name. When you click the Save button only then does the app know
for sure what you want to use and only then does it check for conflict
or not. Again, the apps don't do file versioning. I don't recall
anyone, and especially no company, clamoring for file versioning to be
implemented within an app. Just imagine the problems with tracking
files if every app employed its own different file versioning scheme.
File versioning is something done at a lower level than at the apps.

Adding file versioning via a service or background process that is
monitoring file replacement will still not alter the behavior of the
Browse dialog in applications. You aren't changing their code. The
apps will still not check for conflict until you click the Save button.
If you use a new filename, like appending a number, then you are not
stepping atop an existing file so file versioning is not relevant. You
are saving to a new file. If, however, you get the conflict alert
prompt from the app and chose to override the file is when the file
versioning software kicks in to save the old instance of the file you
just overwrote.

In the video below, you are using Windows Explorer to access the old
versions stored in System Restore snapshots. The apps don't do the file
versioning. The OS (well, the backup or snapshot program) is saving the
old instances of an overwritten file. You'll see in the video that you
use Windows Explorer to access the file versioning support in the OS.

(at the 0:40 timemark on how to select an old overwritten version)
(at the 4:00 timemark on how to configure Backup to do file versioning)

(hey, that wasn't my choice for a desktop background)
(at 2:00 timemark, shows Previous Versions property tab on a folder)
(use the Previous Versions content menu entry for an existing file)

However, file versioning will retain only so many copies of old
instances of a file (that was repeatedly overwritten). If the app is
digging into System Restore then you only get the granularity afforded
by that function to find old versions of a file and only as far back as
System Restore retains its oldest snapshot. In UNIX, I believe (or
maybe it was Exec for the Unisys 1100 mainframes), you can enable file
versioning as part of the OS and also specify how many old versions you
can keep. The default was 3 but could be set up to 64. In Windows 7,
you use the System Restore service to keep old copies of an overwritten
file at the granularity afforded by the System Restore service.

However, although file versioning lets you access old instances of
overwritten files, you still only get one copy of the file you can
access. Consider it like a Rolodex card file where you can spin through
all the cards but you only read one at a time. These old versions do
NOT have some number appended to them. They all have the SAME filename.
Just like any backup program, you select an old instance to restore and
it steps atop the existing available copy of that file.

The applications don't do file versioning. They can't because they
won't know what different scheme might be employed by some other
application. File versioning is done in the OS (by some service or
background process that monitors file operations). File versioning
doesn't append numbers onto files but just keeps old copies of the file
and under the same name.

You could use a 3rd party backup, synchronization, or snapshot program
that is set to very small update intervals, like 5 minutes, to do
incremental backups but that will miss any changes to files between the
backups. For a real file versioning setup, you need to use a
kernel-mode driver that intercepts all file operations so the driver can
see all the file I/O requests as they occur, not poll for changes
sometime later. When the file gets changed (after releasing the handle
on the file) then the driver would save a backup copy of the old
instance before allowing saving of the new changes. The whole old file
isn't changed, just the incremental changes made to the file.

You want the apps to do the file versioning. Apps are written by
different authors so each app would employ a different file versioning
scheme. That means inconsistent methods. So apps don't do file
versioning. Something else does that either through backups and the
granularity of how often they save or through on-access methods (e.g.,
driver monitoring of system calls for file I/O) to ensure all old
instances are retained. Apps don't work at those levels.

Seriously? 200+ lines of text that essentially says the same thing a
dozen different ways? Dude...

 

[VanguardLH]

I'm having trouble finding a scenario where right clicking on a file
doesn't select it. I don't have much hope of finding it because most
apps use the common Windows dialogs, so their behavior is necessarily
standardized.

I'm talking about where you right-click on an object INSIDE the program,
like a node in a tree list (say, for a folder - which has NOTHING to do
with the file system but merely how the data is organized within the
application). When you click on a tree node, it gets selected. When
you right-click on a tree node, it may not get selected. The context
menu is still showing actions for the node on which you right-clicked
but if you later do some other action, like from a toolbar, then what
you last right-clicked on may not be the selected object.

I don't remember if it was a newsreader or e-mail client where I saw
this. It would show a list of folders or some data grouping in a tree
list on the left side. I'd right-click on a tree node to select some
action from the context menu. Because I had right-clicked on that node
and because I saw the highlight change to that tree node, I figured it
was the selected node, too. Nope, so the menu/toolbar action was
against the actual selected tree node instead of the one that I had just
right-clicked on.

This is not an issue with the common browser dialog presented by Windows
that an app might call up. I'm talking about the UI for the app itself.

 

[VanguardLH]

Char Jackson wrote:

VanguardLH wrote:

Metspitzer wrote:

Windows picks a name for an untitled document. If the untilled
document exists already, why not add a 1 to the filename?

Windows does not pick names for documents. Your APPLICATION does
that but you never mentioned the application you are using.

When you load your unidentified application to create a document,
it's not likely it will consume gobs of memory in preparation for
your work on the document since it won't know the size of the
document. Your application is going to create a [sometimes
temporary] file which can be expanded as needed as you add more to
the document.

So what *application* are you using to create a new document?

That middle paragraph is oddly out of place. Does the size of a
document play a role in how its default name is generated?

What I meant is Windows isn't going to allocate all of available memory
for a file space since it won't know how big will be the file. It will
load the application into memory (a portion of it) and the application
might allocate a buffer in which it loads a portion of the file.
Whether temporary or the target file, the app is going to create a file
for the new document, not Windows.

Fair enough, but still 100% unrelated to the OP's question about
default filenames.

Then why did YOU ask your question?

I was trying to gently guide you into understanding that your middle
paragraph was 100% unrelated to the OP's question. Instead of picking
up on what I was trying to point out, you blindly forged ahead, still
100% unrelated to the OP's question about file names.

You asked, I answered,

Your answer should have been "No, and I apologize for wandering off on
a tangent", but that's not what happened.

and now it's unrelated?

It was always 100% unrelated. I'm sure you see that now.

No, it wasn't unrelated to YOUR question in your subthread.
Was my prior reply unrelated? No, because it says the app might create
a memory buffer for the document but the app is still the culprit that
creates a file.

You'll probably want to rethink that.

What you did is what is colloquially considered to be a "Microsoft
answer". What that means is that the information you provided was
factually correct, but it had absolutely nothing to do with the
question being asked.

When you load an application which generates a "new" document, does it
always create a file? NO! It might start out using a buffer. WHERE is
that buffer? Geez, this is really that hard for you to figure.

In the examples that the OP gave for apps creating new docs when they
were loaded, none of them created a temporary file. They all use a
buffer in memory. Not until you save the new doc does the app create a
file. And it's the app that creates the file that YOU specified.

The OP suggested that the apps he listed created temp files. Nope, they
create buffers in memory. Come on, follow the discussion. It's not
that hard.

 

[R. C. White]

Hi, Gene.

Your "heat of the battle" scenario is the one I mean:

The file may or may not be highlighted and turned blue in the file list, but
its name now appears in the "File name:" box of the Save or Save As dialog
window. When I am vigilant, I can simply correct the name, but "in the heat
of the battle", I might just press <Enter> - and the damage is done.

Like you, I can't make this happen on demand and, when it does happen, I'm
too rushed and frustrated to investigate. Besides, MY problem is soon fixed
and I just go on to other priorities.

RC
--
R. C. White, CPA
San Marcos, TX
(e-mail address removed)
Microsoft Windows MVP (2002-2010)
Windows Live Mail 2011 (Build 15.4.3555.0308) in Win7 Ultimate x64 SP1


"Gene E. Bloch" wrote in message

On Fri, 06 Apr 2012 11:18:25 -0700, Gene E. Bloch

I think the scenario that R.C. described is flat wrong. Your scenario,
however, seems possible.

Using the standard Windows theme, when a file is selected it is
highlighted in a shade of blue. When a second file is hovered over, it
becomes a nearly identical shade of blue, only the slightest bit
lighter. It would be very easy to see the hovered file and its
highlight and assume that it's the selected file, especially if the
selected file is scrolled out of view. Further, I've read that
selecting a folder (in the left pane of Windows Explorer) will allow a
file in the right pane that was previously selected to retain its blue
selection attribute. Obviously, you can't select a folder in the left
pane AND a file in the right pane at the same time, so that could be
confusing and could lead to errors (and possible data loss).

Does that sound like what you're seeing?

P.S. Didn't we touch on this same subject during "the great Library
debate" awhile back? You had noticed some file-selection weirdness,
IIRC, and had included it as one of several reasons why you didn't use
Libraries. I could be misremembering, though.

It seems like when I click on a file the other entity remains selected,
in view or not, and this is confusing at best...which is why it sounds
like what I'm seeing, but maybe it isn't quite that...

Yes, we did discuss this (or something similar) with respect to
Libraries, and later I posted that I had seen it (or something similar)
happen outside of any Library context.

For me the upshot of it is that in the heat of battle, my perceptions
may be (and surely *are*) confused, and I haven't yet managed to be in
a situation where I have (or take) a few seconds to try to see what is
actually happening. I.e., I react too quickly and thereby lose the
opportunity to investigate...

So I'll at least try to watch what is happening so I can avoid trouble,
and maybe I'll even get a clear idea of what is happening. But until
then, I'd better avoid sounding definitive.

And now you also have an idea why I inserted the parenthetical "or
something similar" above

 

[Bob Hatch]

I will give it a shot.
Thanks

The nice thing is that it "lives" on the task bar. When you want to see
your notes, click on it. When you want a clean desktop, click on it. You
can change color and sizes of each note and you can use them as a
temporary holder for cut and paste stuff.

 

[Char Jackson]

I'm talking about where you right-click on an object INSIDE the program,
like a node in a tree list (say, for a folder - which has NOTHING to do
with the file system but merely how the data is organized within the
application). When you click on a tree node, it gets selected. When
you right-click on a tree node, it may not get selected. The context
menu is still showing actions for the node on which you right-clicked
but if you later do some other action, like from a toolbar, then what
you last right-clicked on may not be the selected object.

I don't remember if it was a newsreader or e-mail client where I saw
this. It would show a list of folders or some data grouping in a tree
list on the left side. I'd right-click on a tree node to select some
action from the context menu. Because I had right-clicked on that node
and because I saw the highlight change to that tree node, I figured it
was the selected node, too. Nope, so the menu/toolbar action was
against the actual selected tree node instead of the one that I had just
right-clicked on.

This is not an issue with the common browser dialog presented by Windows
that an app might call up. I'm talking about the UI for the app itself.

I assume that behavior was limited to a single application, and since
we don't know what it was, it'll remain a mystery. Besides the app
name, the other unknown is whether it's an app some of us are likely
to be using. We may never find out.

 

[Char Jackson]

Char Jackson wrote:


Char Jackson wrote:

VanguardLH wrote:

Metspitzer wrote:

Windows picks a name for an untitled document. If the untilled
document exists already, why not add a 1 to the filename?

Windows does not pick names for documents. Your APPLICATION does
that but you never mentioned the application you are using.

When you load your unidentified application to create a document,
it's not likely it will consume gobs of memory in preparation for
your work on the document since it won't know the size of the
document. Your application is going to create a [sometimes
temporary] file which can be expanded as needed as you add more to
the document.

So what *application* are you using to create a new document?

That middle paragraph is oddly out of place. Does the size of a
document play a role in how its default name is generated?

What I meant is Windows isn't going to allocate all of available memory
for a file space since it won't know how big will be the file. It will
load the application into memory (a portion of it) and the application
might allocate a buffer in which it loads a portion of the file.
Whether temporary or the target file, the app is going to create a file
for the new document, not Windows.

Fair enough, but still 100% unrelated to the OP's question about
default filenames.

Then why did YOU ask your question?

I was trying to gently guide you into understanding that your middle
paragraph was 100% unrelated to the OP's question. Instead of picking
up on what I was trying to point out, you blindly forged ahead, still
100% unrelated to the OP's question about file names.

You asked, I answered,

Your answer should have been "No, and I apologize for wandering off on
a tangent", but that's not what happened.

and now it's unrelated?

It was always 100% unrelated. I'm sure you see that now.

No, it wasn't unrelated to YOUR question in your subthread.
Was my prior reply unrelated? No, because it says the app might create
a memory buffer for the document but the app is still the culprit that
creates a file.

You'll probably want to rethink that.

What you did is what is colloquially considered to be a "Microsoft
answer". What that means is that the information you provided was
factually correct, but it had absolutely nothing to do with the
question being asked.

When you load an application which generates a "new" document, does it
always create a file? NO! It might start out using a buffer. WHERE is
that buffer? Geez, this is really that hard for you to figure.

No one suggested that a temp file is created. You made that part up.
In fact, you made up the whole 'temp file in buffer' part, because
none of that was in the OP's post. He asked about filenames, not temp
files and buffers.

In the examples that the OP gave for apps creating new docs when they
were loaded, none of them created a temporary file. They all use a
buffer in memory. Not until you save the new doc does the app create a
file. And it's the app that creates the file that YOU specified.

There you go, off on another tangent.

The OP suggested that the apps he listed created temp files. Nope, they
create buffers in memory. Come on, follow the discussion. It's not
that hard.

We must be reading different threads because the OP suggested none of
that.

 

[Char Jackson]

Hi, Gene.

Your "heat of the battle" scenario is the one I mean:


The file may or may not be highlighted and turned blue in the file list, but
its name now appears in the "File name:" box of the Save or Save As dialog
window. When I am vigilant, I can simply correct the name, but "in the heat
of the battle", I might just press <Enter> - and the damage is done.

Like you, I can't make this happen on demand and, when it does happen, I'm
too rushed and frustrated to investigate. Besides, MY problem is soon fixed
and I just go on to other priorities.

RC

The simplest explanation is probably the right one. When you think
you're only hovering over a filename, you're unintentionally clicking
on it and selecting it. I don't think there's any documented evidence
that hovering, by itself, can select a file.

 

[Dave-UK]

The simplest explanation is probably the right one. When you think
you're only hovering over a filename, you're unintentionally clicking
on it and selecting it. I don't think there's any documented evidence
that hovering, by itself, can select a file.

Actually there is a setting in Folder options on the General tab
to 'Point to select'. I've just tried it and the arrow cursor
changes to a pointed hand which selects on hovering over a file!

 

[Gene E. Bloch]

The simplest explanation is probably the right one. When you think
you're only hovering over a filename, you're unintentionally clicking
on it and selecting it. I don't think there's any documented evidence
that hovering, by itself, can select a file.

Except I don't think hovering selects a file. As Dave-UK just
mentioned, it can be so set, but I always keep that setting off.

My 0.003-baud brain has dredged up a vague memory that what I have done
is right-clicked a filename, chosen something from the pop-up menu, and
found that the file being operated on is *not* the one I right-clicked.

None-the-less, I remain aware that my memory of the sequence(s) of
steps I have taken to cause this is confused.

And it is frustrating...

 

[Gene E. Bloch]

Gene E. Bloch wrote:

I suspect that comes from you right-clicking on a file (which makes it
look highlighted) and then selecting an action from the context menu
versus you left-clicking on the file to actually select it.
Right-clicking on a file doesn't actually select the file. I've done
that several times. I right-click on a file, thought it was selected,
and then committed an action but it was for the actual selected file.
So to be sure that I select a file, I left-click on it before
right-clicking on it - but that's only in some applications. It seems
to be a defect in the Browse dialog or tree list within an application
where right-clicking on a file doesn't not also mean it is selected.

Interesting. In rply to Char jackson a few posts up, I just posted
comments saying that's what I might have done.

Thanks for:

a. Clarifying it for me

b. Verifying that I'm (maybe) not crazy