Adding a note to a File Name?

[Char Jackson]

On 8/25/13 2:40 PM, Char Jackson wrote:

I think the point you may be missing is what the first time, average
user expects. That person expects/thinks (s)he is working with a copy
of a file when working in the library. They don't realize they are
working with the original file. Thus, when they do something to a file
they see, they screw up the original, and not the copy they think they
are working with.

I think a tiny handful of people have fallen into that trap, and since then
their story has been repeated ad nauseam to the point where they've become
legendary. For all of the rest of us, there haven't been any problems of
this kind.

Once you understand the difference is for a library vs. the standard
folder, you're correct. But as I said, the average user doesn't
understand this when first exposed to Libraries, and that user often
tosses something (s)he doesn't want tossed.

I don't see how that's possible. When working in Windows Explorer, deleting
a file in a Library folder and deleting a file in a non-Library folder do
exactly the same thing: they both delete the file. Since there's no
difference, I don't think the tiny number of users who are having problems
can blame anyone but themselves.

If anything, Libraries are safer, not more dangerous, because while deleting
files is the same in either paradigm, deleting folders is safer in a Library
folder (because the folder isn't actually deleted, it's just removed from
the Library view).

I found the Windows Help Files to not be particularly clear as to how
the Libraries function.

I had a different experience and found the Help file on this topic to be
exceedingly clear. I wasn't always able to say the same about earlier
Windows Help topics.

 

[Ken Springer]

The ".." isn't just an old CLI thing. That notation is widely used in
modern programming, including HTML, for "parent directory". Similarly,
but less commonly, "." for "this directory". However today's programs in
general do not, I imagine, actually reference the dotted directory
entries.


Fair enough, but I didn't say that the folder wasn't showing the
contents of the directory. I was arguing against the notion (which might
or might not have come from you, but has been snipped) that the folder
and the directory were the same thing. I hope we can agree that they
aren't.

To me, if the window is displaying a Library folder, it's not a
directory. If it's displaying the contents of a hard drive location,
i.e. D:\Data\Photo\xxxxxxxx.yyy, with or without the file extension, it
is the same as a directory. Having a "." or ".." is a redundant thing
to me, since the change in the Explorer windows starting with Vista.

Hmmmm, I guess we half agree! LOL

You're right, though, when vendors start using icon A, which started out
meaning just one thing, and start using the same graphic for something
else, the meaning of that icon gets muddled. They should at least
modify it to the point that most users will/may think there's something
different and it's not original meaning.

But, I guess it's just like language, one word can have different meanings.

Although directories and folders are different, there are common
features, and that's one of them.


Understood, no problem. If you wanted to pick a fight with me you'd have
to try an awful lot harder than that.

Too much work! LOL


--
Ken

Mac OS X 10.8.4
Firefox 23.0
Thunderbird 17.0.8
LibreOffice 4.1.04

 

[Ken Springer]

I think a tiny handful of people have fallen into that trap, and since then
their story has been repeated ad nauseam to the point where they've become
legendary. For all of the rest of us, there haven't been any problems of
this kind.

I don't think there's any way we can ever know with any reasonable
accuracy how many users have deleted files they didn't want to, and had
no way to replace them. There's also that group of users that are using
Libraries and haven't discovered the difference. Plus, the number of
users who totally don't get the Library concept and don't use them at all.

I don't see how that's possible. When working in Windows Explorer, deleting
a file in a Library folder and deleting a file in a non-Library folder do
exactly the same thing: they both delete the file. Since there's no
difference, I don't think the tiny number of users who are having problems
can blame anyone but themselves.

It depends on what you think is happening. It's not a question of the
deleting itself, but a question of where the file is being deleted from.

Let's say you have 2 cardboard boxes. One is called Library, the other
Photos. The user looks in the Library box, and sees the contents of the
Photos box. The Library box is just a window into the Photos box, but
the user doesn't realize this. The user thinks what they see is a true
copy of the file, not just a window to the file. When the user sees a
file in the Library box they don't want there, they delete the file in
the Library, not knowing/realizing they are actually deleting the file
from the Photos box.

Some of the problem may come from the impression the Library contents
can be modified to show just X number of Y files from a folder. So,
they delete the file from the Library folder so it shows only the photos
they want in that Library. I know that's what I wanted from Libraries,
but the normal working of a Library won't let you do that.

There are also the group who use Libraries but have yet to delete
anything while in a Library. They've not discovered/learned what really
happens. I told a friend how Libraries behave when deleting files from
a Library, and you should have seen the look of horror on her face. So
I made a brownie point or two by preventing her from throwing away some
irreplaceable photos.

If anything, Libraries are safer, not more dangerous, because while deleting
files is the same in either paradigm, deleting folders is safer in a Library
folder (because the folder isn't actually deleted, it's just removed from
the Library view).

Agreed, but I'm not sure what percentage of Library uses realize this
too. As I've hinted, it would be nice if this is what happened with
individual files also.

I had a different experience and found the Help file on this topic to be
exceedingly clear. I wasn't always able to say the same about earlier
Windows Help topics.

I have to give MS credit, starting with Vista, their help files have
improved. I've not looked at the Win8 help files as of yet.

Current Windows help files are certainly better that what comes with
Mountain Lion, which is what I have installed on this Mac.


--
Ken

Mac OS X 10.8.4
Firefox 23.0
Thunderbird 17.0.8
LibreOffice 4.1.04

 

[pyotr filipivich]

Extensions aren't really a Unix thing. They are there, of course, but
they are for human use. The OS does not use the extension to figure
out what to do with the file as DOS and Windows do.

Which is fine by me. Hey, if I want to edit the Canard with a
text editor when it is a compiled program file - UNIX is fine with
letting me do that.
UNIX doesn't have "extensions" - but I can name a file with
multiple "dots" (e.g., letters.880203.nka) which makes the human
interface "better". As I have said, who cares what actually happens
when I press the buttons - magic elves can be painting letters on the
screen for all I care (so long as they put up the right letter.).

As for file names - the Unix file system is very case sensitive. So
you can have files named myFile.txt, Myfile.txt, and myfile.txt in the
same directory. They are three different files and the OS won't mix
them up. NTFS preserves case in file names but searches for file names
are case insensitive, so NTFS could not make sense of those three
files in the same directory.

I don't think there's any OS/file system that will let you have
multiple files with exactly the same name in a directory - how would
you tell it which one to use?

The complaint seems to be (and I agree) is that Windows hides the
extension. Which means you can have a directory listing of
Zathras,
Zathras,
Zathras,
Zathras,
Zathras,
Zathras,
Zathras,
Zathras,
Zathras, and
Zathras.
with no way to know which Zathras is the file you want. Yes, I will
agree, to name the all the same thing might be a bad idea. But I did
not. With extensions not hidden, I get a directory listing of
Zathras.txt,
Zathras.bat,
Zathras.dat,
Zathras.idx,
Zathras.doc,
Zathras.csv,
Zathras.xls,
Zathras.bak,
Zathras.dwg, and
Zathras.
On the other hand, having given them all a similar name, and a
different extension, makes other file management "simpler".

It originated as a command line system, there wasn't anything else at
that time. And nearly all users communicated with the machine at
speeds we now consider incredible slow, some like 300bpm. That's why
the commands and arguments are so terse. Nowadays there are several
different GUIs and windowing environments, I don't think your
statement applies to Unix any more or less than it does to Windows.

compare
rm * /r
with
del *.* /s
Unix will execute with no verification, "obviously" expecting you to
know what you are doing. Windows, like a hyperactive Boy Scout it has
to tell me everything it is doing, and verify everything I do with a
warning. Heck, Windows is still warning me that changing a file name
from "test.txt" to "test.bat" may cause the file to be unusable. "I
know. I heard you the first time 30 years ago. Now shut up and get
out of my way!"

Anyway, I find that there are numerous occasions where the GUI
"doesn't work", and I have to get to a command prompt and "beat it
into submission". Such as when I wanted to sync files on the home
computer with ones on the laptop - and vice versa. Or to get the
application data from off the school computer to a backup, so that
when I log into another computer, I don't have to reset all the
options "by hand". Those are, naturally, now batch files, and I don't
have to think about them, too much.

tschus
pyotr

 

[Mike Barnes]

The complaint seems to be (and I agree) is that Windows hides the
extension. Which means you can have a directory listing of
Zathras,
Zathras,
Zathras,
Zathras,
Zathras,
Zathras,
Zathras,
Zathras,
Zathras, and
Zathras.
with no way to know which Zathras is the file you want.

Several points to note.

1. Hiding extensions is a Windows option. I deplore the fact that it's
the *default* option, but it is an option, it is possible to deselect
it, and smart users do just that.

2. What you've illustrated is actually a folder display. The term
"directory listing" usually refers to the output of the "dir" command,
in which the extension is never hidden.

3. Your illustration omits the icon which appears in a folder display
and generally serves to identify the file you want. For further
clarification, the "Details" view also has a "Type" column.

Yes, I will
agree, to name the all the same thing might be a bad idea. But I did
not.

Having the same base name is perfectly sensible if the files are
directly related and the "hide extensions" option is deselected. I do
that quite a lot, particularly where the same information is stored in
more than one format.

 

[pyotr filipivich]

Several points to note.

1. Hiding extensions is a Windows option. I deplore the fact that it's
the *default* option, but it is an option, it is possible to deselect
it, and smart users do just that.

What I find "interesting" is that if the extension are hidden, it
seems it is not possible to make a text file into a batch file.

2. What you've illustrated is actually a folder display. The term
"directory listing" usually refers to the output of the "dir" command,
in which the extension is never hidden.
Right.

3. Your illustration omits the icon which appears in a folder display
and generally serves to identify the file you want. For further
clarification, the "Details" view also has a "Type" column.

And that is my preferred view - I want more than just the file
name.

Having the same base name is perfectly sensible if the files are
directly related and the "hide extensions" option is deselected. I do
that quite a lot, particularly where the same information is stored in
more than one format.

Or was I've done; one file is the program code, another the
compiled program, others the input data and output results. And so
forth.

tschus
pyotr

 

[Bob I]

What I find "interesting" is that if the extension are hidden, it
seems it is not possible to make a text file into a batch file.

fairly simple really, do the following

Shift+Right-click, Open command window here

<then type>

ren filename.txt filename.bat

press enter

exit

press enter







<SNIP>

 

[pyotr filipivich]

fairly simple really, do the following

Shift+Right-click, Open command window here

<then type>

ren filename.txt filename.bat

press enter

exit

press enter

LOL. Yep, - there are so many things which are simple, once some
one goes into the details of how they work. (I'm hacking my way
through some CAD software, and it mostly seems counter intuitive.)

I believe the sign in the research facility supposedly read: "The
solution to the problem, once found, will in retrospect seem so
obvious, we will all wonder why we didn't find it sooner."