396,321 Members | 2,193 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 396,321 IT Pros & Developers. It's quick & easy.

When did Windows start accepting forward slash as a path separator?

Stephen Ferg
P: n/a
I have a question that is not directly Python-related. But I thought
I'd ask the most erudite group that I know... :-)

When did Windows start accepting the forward slash as a path separator
character?

At one time, it was accepted as a truism that Windows (like MS-DOS)
was different from Unix because Windows used the backslash as the path
separator character, whereas Unix used the forward slash.

But now, among a small group of cognoscenti, it is a truism that this
is a myth, and that Windows will allow you to use either the forward
or the backward slash as a pathname separator.

I hypothesize that originally Windows accepted only the backslash, and
then at some time it changed to accept the forward slash as well.
Does anyone know when that change occurred? Was it with the
introduction of support for long filenames in NT and Win95?
Jul 18 '05 #1
Share this Question
Share on Google+
30 Replies


Ben Finney
P: n/a
On 25 Sep 2003 16:50:49 -0700, Stephen Ferg wrote:
But now, among a small group of cognoscenti, it is a truism that this
is a myth, and that Windows will allow you to use either the forward
or the backward slash as a pathname separator.


I highly doubt it, since the forward slash (or just "slash") is the
conventional Windows command-line option indicator, analogous to the
hyphen on Unix. To accept it as the start of a filename would break
zillions of existing systems, for no appreciable benefit to Microsoft.

Python automagically determines the path component separator, os.sep,
and uses it for most file path transformations to and from the internal
language's '/'.

<http://www.python.org/doc/2.3.1/lib/os-path.html#l2h-1552>

Is this perhaps what gives you the impression?

--
\ "I went to a restaurant that serves 'breakfast at any time'. So |
`\ I ordered French Toast during the Renaissance." -- Steven |
_o__) Wright |
Ben Finney <http://bignose.squidly.org/>
Jul 18 '05 #2

Bob Gailer
P: n/a
At 05:50 PM 9/25/2003, Stephen Ferg wrote:
I have a question that is not directly Python-related. But I thought
I'd ask the most erudite group that I know... :-)

When did Windows start accepting the forward slash as a path separator
character?


Good question. Certainly later than:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>cd /samis
The syntax of the command is incorrect.

Bob Gailer
bgailer@alum.rpi.edu
303 442 2625
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003

Jul 18 '05 #3

Andrew Dalke
P: n/a
Stephen Ferg:
When did Windows start accepting the forward slash as a path separator
character?
DOS 2. When directories were introduced. Many of the functions
were based on unix, down to a NUL terminated filename and the
name "creat".

But DOS 1 was modelled on CP/M which used "/" as a command
line option flag. You couldn't use a "/" in the DOS shell because
it would be interpreted as the flag. You could change the flag using
a DOS command, eg, to use "-" instead, but that was disabled in
the 3.x days; for good reason.

Hence, the low-level DOS commands (since 2.0) would take
both / and \ as separators, but some codes did their own
filename munging and would not.
At one time, it was accepted as a truism that Windows (like MS-DOS)
was different from Unix because Windows used the backslash as the path
separator character, whereas Unix used the forward slash.
It was? My copy of Norton's Guide to the IBM PC makes
the explicit statement that directories were directly influenced by
unix. I actually regard this as a point of similarity. The character
used is a minor issue.

There are, of course, many ways in which they are different. Like
drive names, which comes from CP/M, and the filesystem layout
itself (FAT vs. inodes). And DOS had much better IDEs, like
Turbo Pascal. ;)
I hypothesize that originally Windows accepted only the backslash, and
then at some time it changed to accept the forward slash as well.
Does anyone know when that change occurred? Was it with the
introduction of support for long filenames in NT and Win95?


The original Windows was a shell on top of DOS. Programs
under Windows could use the DOS layer directly, which took
both separators. Even in Wn95 I could exit to DOS, meaning
I could quite out of Win95 to the shell prompt then do 'win'
to start it up again.

Andrew
dalke@dalkescientific.com
Jul 18 '05 #4

Michael Geary
P: n/a
Stephen Ferg wrote:
When did Windows start accepting the forward slash as a path separator
character?

At one time, it was accepted as a truism that Windows (like MS-DOS)
was different from Unix because Windows used the backslash as the path
separator character, whereas Unix used the forward slash.

But now, among a small group of cognoscenti, it is a truism that this
is a myth, and that Windows will allow you to use either the forward
or the backward slash as a pathname separator.

I hypothesize that originally Windows accepted only the backslash, and
then at some time it changed to accept the forward slash as well.
Does anyone know when that change occurred? Was it with the
introduction of support for long filenames in NT and Win95?


Hi Steve,

Every version of Windows has accepted "/" as a path separator. So has every
version of MS-DOS beginning with DOS 2.0 (the first version that had
subdirectories).

It's only been in command lines that "/" was not allowed, because it had
already been used as a switch delimiter in MS-DOS 1.0.

-Mike
Jul 18 '05 #5

Michael Geary
P: n/a
> Stephen Ferg wrote:
But now, among a small group of cognoscenti, it is a truism that this
is a myth, and that Windows will allow you to use either the forward
or the backward slash as a pathname separator.

Ben Finney wrote: I highly doubt it, since the forward slash (or just "slash") is the
conventional Windows command-line option indicator, analogous to the
hyphen on Unix. To accept it as the start of a filename would break
zillions of existing systems, for no appreciable benefit to Microsoft.


Actually, every version of Windows, and every version of MS-DOS from 2.0 on,
has accepted "/" as a path delimiter.

Don't confuse the command line with the Windows or DOS kernel. Most command
lines don't allow "/" because it conflicts with the use of "/" for a switch
deliminer. But the Windows and DOS kernels are happy with either "\" or "/".

-Mike
Jul 18 '05 #6

Andrew Dalke
P: n/a
Bob Gailer:
Good question. Certainly later than:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>cd /samis
The syntax of the command is incorrect.


The shell is parsing the line and interprets the "/" as a
command-line flag, Try a relative path, like

cd ./samis

Andrew
dalke@dalkescientific.com
Jul 18 '05 #7

Grant Edwards
P: n/a
In article <b16e4ef7.0309251550.724a57f@posting.google.com> , Stephen Ferg wrote:
When did Windows start accepting the forward slash as a path separator
character?
Sometime prior to 1983. DOS has always accepted it, and I assume Windows
always has as well.
At one time, it was accepted as a truism that Windows (like MS-DOS)
was different from Unix because Windows used the backslash as the path
separator character,
Accepted as a truism by whom? DOS would accept either. The shell's "switch"
character was configurable as well -- it defaulted to '/' but changing it to
'-' was trivial.
whereas Unix used the forward slash. But now, among a small group of cognoscenti, it is a truism that this
is a myth, and that Windows will allow you to use either the forward
or the backward slash as a pathname separator.
I don't remember if the actual DOS system calls accepted '/' or if the C
library translated. I do know that DOS C programs could use '/' for path
separator at least 20 years ago.
I hypothesize that originally Windows accepted only the backslash, and then
at some time it changed to accept the forward slash as well.
Nope. AFAIK, it's always accepted '/'. I did C programming on DOS for
years, and I always used '/' since it was too error working with string
literals in C that contain '\'. Those same programs seemed to run fine
under Windows.
Does anyone know when that change occurred? Was it with the introduction of
support for long filenames in NT and Win95?


I'm not aware that there has ever been a "change". '/' has been OK since
the early DOS days.

--
Grant Edwards grante Yow! WHOA!! Ken and
at Barbie are having TOO
visi.com MUCH FUN!! It must be the
NEGATIVE IONS!!
Jul 18 '05 #8

Grant Edwards
P: n/a
In article <slrnbn74ch.s2.bignose-hates-spam@rose.localdomain.fake>, Ben Finney wrote:
But now, among a small group of cognoscenti, it is a truism that this is a
myth, and that Windows will allow you to use either the forward or the
backward slash as a pathname separator.
I highly doubt it, since the forward slash (or just "slash") is the
conventional Windows command-line option indicator,


That was configurable back in the DOS days. There was a "well-known" byte in
system RAM that contained the "switch" character. IIRC, DOS even shipped
with a utility to change that value.
analogous to the hyphen on Unix. To accept it as the start of a filename
would break zillions of existing systems, for no appreciable benefit to
Microsoft.
Forward slashes always worked fine for me.
Python automagically determines the path component separator, os.sep,
and uses it for most file path transformations to and from the internal
language's '/'.

<http://www.python.org/doc/2.3.1/lib/os-path.html#l2h-1552>

Is this perhaps what gives you the impression?


Forward slashes work in C as well.

--
Grant Edwards grante Yow! Yow! It's some people
at inside the wall! This is
visi.com better than mopping!
Jul 18 '05 #9

Michael Geary
P: n/a
Grant Edwards wrote:
I don't remember if the actual DOS system calls accepted '/' or if
the C library translated. I do know that DOS C programs could
use '/' for path separator at least 20 years ago.


It was the DOS system calls.

-Mike
Jul 18 '05 #10

Jules Dubois
P: n/a
On 25 Sep 2003 16:50:49 -0700, in article
<b16e4ef7.0309251550.724a57f@posting.google.com> , Stephen Ferg wrote:
When did Windows start accepting the forward slash as a path separator
character?


Even MS-DOS 3.3 would accept '/'; the command-line utilities were
programmed to use only '\' without some start-up parameter (PATHSEP?).
Microsoft removed that feature in v4.0 or 5.0. The "kernel" didn't care.

The Windows kernels are the same. The internals of the operating system
accept either.
Jul 18 '05 #11

Tim Roberts
P: n/a
Grant Edwards <grante@visi.com> wrote:

Ben Finney wrote:
But now, among a small group of cognoscenti, it is a truism that this is a
myth, and that Windows will allow you to use either the forward or the
backward slash as a pathname separator.


I highly doubt it, since the forward slash (or just "slash") is the
conventional Windows command-line option indicator,


That was configurable back in the DOS days. There was a "well-known" byte in
system RAM that contained the "switch" character. IIRC, DOS even shipped
with a utility to change that value.


Yes, indeed. There was a SWITCHAR option in config.sys, and a
corresponding DOS service, until DOS 3.0, when it was removed because they
couldn't make it work with network software.

So, the situation can be summed up rather simply:

* All DOS services since DOS 2.0 and all Windows APIs accept either
forward slash or backslash. Always have.

* None of the standard command shells (CMD or COMMAND) will accept
forward slashes. Even the "cd ./tmp" example given in a previous post
fails.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Jul 18 '05 #12

Andrew Dalke
P: n/a
Tim Roberts:
* None of the standard command shells (CMD or COMMAND) will accept
forward slashes. Even the "cd ./tmp" example given in a previous post
fails.


Yup. I should have copy&pasted rather than just type it in.
It should have been in quotes. The following does work for me

E:\dalke>cd ..

E:\>cd /dalke
The system cannot find the path specified.

E:\>cd ./dalke

E:\>cd "./dalke"

E:\dalke>ver

Windows NT Version 4.0

E:\dalke>

Andrew
dalke@dalkescientific.com
Jul 18 '05 #13

Alex Martelli
P: n/a
Grant Edwards wrote:
...
Nope. AFAIK, it's always accepted '/'. I did C programming on DOS for
years, and I always used '/' since it was too error working with string
literals in C that contain '\'. Those same programs seemed to run fine
under Windows.
Does anyone know when that change occurred? Was it with the introduction
of support for long filenames in NT and Win95?


I'm not aware that there has ever been a "change". '/' has been OK since
the early DOS days.


I _think_ (can't be sure...) that at a C-libraries level the switch
occurred either between DOS 1.0 and 1.1, or at the time of release of
2.0. It's hard to say, because MS didn't release a C compiler as a
product back then; however, it seems that, internally, they used C
compilers running on their Unix machines (presumably their own version
of Unix, named Xenix, which they later sold to SCO) to generate some
parts of the DOS stuff of that age. The original QDOS ("Quick and
Dirty OS") that they bought out and resold as DOS 1.0 surely had no
knowledge of forward slashes -- it was basically CP/M disassembled,
hacked and reassembled (all quite illegally of course). Just as surely,
DOS 2.0 had that knowledge (Allen had also hacked into it some Unix
idioms such as I/O redirection and pipes -- some "pipes", redirecting
to a temporary file and then back out of it!, but syntactically Unixoid --
and more generally made it an uneasy mixmash of some concepts and
practice from the CP/M world plus a little from Unix traditions); and
so did the first C compiler, self-hosted on DOS, that MS later sold to
the public (having bought it, I believe, from Lattice).
Alex

Jul 18 '05 #14

Grant Edwards
P: n/a
In article <GpScb.123559$hE5.4229137@news1.tin.it>, Alex Martelli wrote:
Does anyone know when that change occurred? Was it with the introduction
of support for long filenames in NT and Win95?


I'm not aware that there has ever been a "change". '/' has been OK since
the early DOS days.


I _think_ (can't be sure...) that at a C-libraries level the switch
occurred either between DOS 1.0 and 1.1, or at the time of release of
2.0.


I don't think 1.0 had a hierarchical filesystem at all did it?

IIRC, it was basically the same as CP/M 2.2 and had nothing other than a
"root" directory on each floppy [IIRC, CP/M 3.x had some concept of multiple
directories on a floppy but it wasn't a tree structured FS with "paths" --
it was more like partitioning a floppy into multiple drive letters.]

By the time I got my hands on IBM machines 2.x was in common use, so I only
had a brief exposure to 1.x.

--
Grant Edwards grante Yow! .. I want to perform
at cranial activities with
visi.com Tuesday Weld!!
Jul 18 '05 #15

Duncan Booth
P: n/a
Grant Edwards <grante@visi.com> wrote in
news:slrnap5gfa.aol.grante@localhost.localdomain:
I _think_ (can't be sure...) that at a C-libraries level the switch
occurred either between DOS 1.0 and 1.1, or at the time of release of
2.0.


I don't think 1.0 had a hierarchical filesystem at all did it?


That is correct, originally DOS like CP/M didn't have a concept of
directories, all file access used file control blocks. When they added
directories in Dos 2.0 they added new int21 calls which supported the
directory paths and these have always accepted either forward or reversed
slashes as path separators interchangeably.

Dos 3.0 added an int21 call to canonicalize pathnames which included
converting all forward slashes to backslashes.

--
Duncan Booth duncan@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
Jul 18 '05 #16

Peter Hansen
P: n/a
Andrew Dalke wrote:

Bob Gailer:
Good question. Certainly later than:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>cd /samis
The syntax of the command is incorrect.


The shell is parsing the line and interprets the "/" as a
command-line flag, Try a relative path, like

cd ./samis


And of course, there's always:

C:\>ver
Windows 98 [Version 4.10.2222]

C:\>cd ./temp
Too many parameters - /TEMP

C:\>cd ./temp"
Too many parameters - /TEMP"

C:\>cd "./temp"

C:\>
But I digress... *you* guys were talking about operating systems. ;-)

-Peter
Jul 18 '05 #17

Ronald Oussoren
P: n/a

On 26 sep 2003, at 5:50, Jules Dubois wrote:

The Windows kernels are the same. The internals of the operating
system
accept either.

That's not entirely true, in WinNT derivatives the backslash is the
real seperator at the kernel level, the Win32 perform some conversion
that allows forward slashes and recognizes special files like CON, PRN,
et.al..

To make live even more interesting, only unicode paths with backslashes
as seperators can address all files (at least when I last looked at it
about 2 years ago). When using unicodepaths you can use '\\?\' as a
prefix on paths to turn off the conversion I mention above (see
http://msdn.microsoft.com/library/de...library/en-us/
fileio/base/naming_a_file.asp). The fun you can have on windows, I've
managed to create files that cannot be removed :-)

Ronald
Jul 18 '05 #18

Stephen Horne
P: n/a
On Fri, 26 Sep 2003 02:05:50 GMT, "Andrew Dalke"
<adalke@mindspring.com> wrote:
Bob Gailer:
Good question. Certainly later than:

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>cd /samis
The syntax of the command is incorrect.


The shell is parsing the line and interprets the "/" as a
command-line flag, Try a relative path, like

cd ./samis


Nope...

F:\>cd ./dev

F:\>cd .\dev

F:\Dev>
Notice how the forward slash version doesn't change directories, but
the back slash version does. My guess is that it is being taken as...

cd . /<unknown option>

The big question being why the unknown option doesn't get an error
message, as it normally does.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
Jul 18 '05 #19

Robin Becker
P: n/a
In article <b16e4ef7.0309251550.724a57f@posting.google.com> , Stephen
Ferg <steve@ferg.org> writes
I have a question that is not directly Python-related. But I thought
I'd ask the most erudite group that I know... :-)

When did Windows start accepting the forward slash as a path separator
character?

At one time, it was accepted as a truism that Windows (like MS-DOS)
was different from Unix because Windows used the backslash as the path
separator character, whereas Unix used the forward slash.

But now, among a small group of cognoscenti, it is a truism that this
is a myth, and that Windows will allow you to use either the forward
or the backward slash as a pathname separator.

I hypothesize that originally Windows accepted only the backslash, and
then at some time it changed to accept the forward slash as well.
Does anyone know when that change occurred? Was it with the
introduction of support for long filenames in NT and Win95?


I seem to remember getting an early C compiler from M$ around 1983/5 and
being pleasantly surprised that '/' was acceptable. So far as I know
this has been true from the earliest days. I suspect it was because of
all the unix C code that people wanted to work without effort.
--
Robin Becker
Jul 18 '05 #20

Stephen Horne
P: n/a
On Fri, 26 Sep 2003 14:44:30 +0200, Ronald Oussoren
<oussoren@cistron.nl> wrote:
The fun you can have on windows, I've
managed to create files that cannot be removed :-)


I've had that one simply by saving a web page in IE. Seriously
annoying.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
Jul 18 '05 #21

Stephen Horne
P: n/a
On Fri, 26 Sep 2003 02:03:10 GMT, "Andrew Dalke"
<adalke@mindspring.com> wrote:
Stephen Ferg:

At one time, it was accepted as a truism that Windows (like MS-DOS)
was different from Unix because Windows used the backslash as the path
separator character, whereas Unix used the forward slash.


It was? My copy of Norton's Guide to the IBM PC makes
the explicit statement that directories were directly influenced by
unix. I actually regard this as a point of similarity. The character
used is a minor issue.


Directly influenced, yes - but as DOS 1 didn't have subdirectories but
did have options marked with '/', the unix subdirectories couldn't be
duplicated exactly in DOS 2. The character used *is* a minor issue,
but it is still a difference - what Stephen Ferg wrote is, I believe,
valid.

Even if DOS was internally happy to accept '/' as a path separator,
still the 'accepted as a truism' bit rings true to me - what is
accepted as an obvious truth is not always actually true, and to most
people users DOS was the command line and Windows was just a shell on
top of DOS - the 'truism' was what people could see, not what was
hidden away in the INT 21h calls that only programmers cared about.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
Jul 18 '05 #22

Bengt Richter
P: n/a
On Sat, 27 Sep 2003 09:47:47 +0100, Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote:
On Fri, 26 Sep 2003 14:44:30 +0200, Ronald Oussoren
<oussoren@cistron.nl> wrote:
The fun you can have on windows, I've
managed to create files that cannot be removed :-)


I've had that one simply by saving a web page in IE. Seriously
annoying.

Do you mean windows exploder will not even delete it with right-click, delete?
Or doesn't it show up at all? (how do you know it exists? dos dir?)

Regards,
Bengt Richter
Jul 18 '05 #23

Andrew Dalke
P: n/a
Stephen Feng:
At one time, it was accepted as a truism that Windows (like MS-DOS)
was different from Unix because Windows used the backslash as the path
separator character, whereas Unix used the forward slash.

Me, arguing that the directory structure between DOS and its Windows
derivatives is a point of similarity, compared to the other differences.

Stephen Horne: Directly influenced, yes - but as DOS 1 didn't have subdirectories ...
Right. I said that as well ... Plus, Stephen's Feng's comparison
is predicated on comparing how directories are accessed, so it's
cheating to go back to when DOS didn't have directories. ;)
what is accepted as an obvious truth is not always actually true,


A truer word has rarely been said.

BTW, the similarity-but-not-the-same between DOS and unix
caused me problems when I started using unix. See, under DOS
there's this great utility called "unerase" which can be used to
recover files accidentally deleted. Only I would deliberately
delete a file in order to probe the system; eg, is this file really
used?

And I wanted to see if the script really used the C compiler....

Had to reinstall IRIX to fix that one.

Andrew
dalke@dalkescientific.com
Jul 18 '05 #24

Cousin Stanley
P: n/a
>>The fun you can have on windows, I've
managed to create files that cannot be removed


I've had that one simply by saving a web page in IE. Seriously
annoying.

| Do you mean windows exploder will not even delete it with right-click, delete?
| Or doesn't it show up at all? (how do you know it exists? dos dir?)

Under Win98 they show up
AND can NOT be deleted from the Right-Click context menu ...

They can be deleted with no problem under DOS ....

The problem in Win98 for me came from saving web pages
with extra LONG file names ....

--
Cousin Stanley
Human Being
Phoenix, Arizona

Jul 18 '05 #25

Stephen Horne
P: n/a
On 27 Sep 2003 17:20:44 GMT, bokr@oz.net (Bengt Richter) wrote:
On Sat, 27 Sep 2003 09:47:47 +0100, Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote:
On Fri, 26 Sep 2003 14:44:30 +0200, Ronald Oussoren
<oussoren@cistron.nl> wrote:
The fun you can have on windows, I've
managed to create files that cannot be removed :-)


I've had that one simply by saving a web page in IE. Seriously
annoying.

Do you mean windows exploder will not even delete it with right-click, delete?
Or doesn't it show up at all? (how do you know it exists? dos dir?)


There was no way I could find to delete it - not even writing a C++
program directly calling the DeleteFile API call.

I don't remember exact details - not even for sure whether it was
Win98 or Win2000 (it was too long ago for WinXP). I do remember that
the non-deletable file was in a deeply nested set of pointless folders
created by saving that web site.

Basically, it ended up sitting on my machine annoying me for ages -
I'm not sure if a new machine or a reinstall put an end to it (it was
my work machine, which tends to get fewer reinstalls).
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
Jul 18 '05 #26

Grant Edwards
P: n/a
In article <YAZd/ks/Kjpc089yn@the-wire.com>, Mel Wilson wrote:
I have a question that is not directly Python-related. But I thought
I'd ask the most erudite group that I know... :-)
When did Windows start accepting the forward slash as a path separator
character?
Internally, the routines in the API have accepted '/' as a path
separator for a long, long time. It's the command-line
processors that kick up a fuss.


And that could always be fixed by running a real shell a-la MKS,
Cygwin, etc.

--
Grant Edwards grante Yow! Hello. I know
at the divorce rate among
visi.com unmarried Catholic Alaskan
females!!
Jul 18 '05 #27

JanC
P: n/a
Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> schreef:
I do remember that the non-deletable file was in a deeply nested set
of pointless folders created by saving that web site.


IIRC that is or was a bug on (some) Windows versions: the path+filename you
have to pass to the Delete File API function could be too long for the
reserved string buffer length (256 bytes), or something like that...

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jul 18 '05 #28

Christos TZOTZIOY Georgiou
P: n/a
On 27 Sep 2003 17:20:44 GMT, rumours say that bokr@oz.net (Bengt
Richter) might have written:
Do you mean windows exploder will not even delete it with right-click, delete?
Or doesn't it show up at all? (how do you know it exists? dos dir?)


I have 110MB (or so they seem) worth of files (2893 files) in my W2k SP4
laptop's c:\recycler\nprotect folder that can't be accessed or deleted.
Norton Protect is long uninstalled, but operating on the files gives
(example):

C:\RECYCLER\NPROTECT\00041753.
The system cannot find the file specified.

The disk shows as healthy in Disk Manager, and scandisk or
what's-its-name runs successfully. Go figure. Ils sont fous ces
Redmontains! (index finger running wild circles)
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.
Jul 18 '05 #29

Christos TZOTZIOY Georgiou
P: n/a
On Sat, 27 Sep 2003 17:22:41 GMT, rumours say that "Andrew Dalke"
<adalke@mindspring.com> might have written:
BTW, the similarity-but-not-the-same between DOS and unix
caused me problems when I started using unix. See, under DOS
there's this great utility called "unerase" which can be used to
recover files accidentally deleted. Only I would deliberately
delete a file in order to probe the system; eg, is this file really
used?
Safe wisdom: mv (move, ren for old DOS) would be better, right?
And I wanted to see if the script really used the C compiler....

Had to reinstall IRIX to fix that one.


If 'inst same' wasn't enough, then that should have been a really old
version of Irix... :(
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.
Jul 18 '05 #30

Andrew Dalke
P: n/a
Christos TZOTZIOY Georgiou:
Safe wisdom: mv (move, ren for old DOS) would be better, right?
Sure. I know that *now*. :)
If 'inst same' wasn't enough, then that should have been a really old
version of Irix... :(
--


A Personal Iris running 3.0.4, in 1990

Andrew
dalke@dalkescientific.com
Jul 18 '05 #31

This discussion thread is closed

Replies have been disabled for this discussion.