AUX File Writing Error

Gabriel Genellina gagsl-py at yahoo.com.ar
Thu Feb 15 10:14:53 EST 2007


En Thu, 15 Feb 2007 11:34:53 -0300, John Machin <sjmachin at lexicon.net>  
escribió:

>> > Probably not. AUX, CON, NUL, PRN, LPT, COM1, COM2 etc (with or without
>> > an extension) are reserved in Windows for specific devices for
>> > compatibility with MS-DOS 1.00 programs, which did that for
>> > compatibility with CP/M.
>>
>> (This is OT now) Do you know why "AUX.csv" is invalid too? I can accept
>> that AUX (without extension) is an invalid filename, but it is quite
>> different from "AUX.csv"
>>
>
> It is actually a valid file name, but the file is not on disk. I
> presume that the OP got an error because it was in 'a' (append) mode
> which requires an existing disk file. See below.
>
> C:\junk>copy con aux.csv
> fubar
> ^Z
>         1 file(s) copied.

The above gives me an "Access denied" error; perhaps because AUX is my  
serial port and it is currently in use.

> Why? Who knows? We're talking CP/M, MS-DOS and Windows and you want to
> know why? Probably too lazy to distinguish between 'AUX\0', 'AUX.\0'
> and 'AUX.XYZ\0' ... probably stopped scanning on reaching the first
> invalid character. If you're desperate to find out, dial up your
> nearest RCPM and ask the sysop :-)

Ahhhh... I think you hit the point, indirectly. On CP/M the filename was  
not stored as 'AUX\0' - remember, ONLY 8 characters plus 3 for extension,  
and NO PATH. A FileControlBlock (FCB) had exactly 11 characters reserved  
for the file name (plus the drive number). So it was actually "AUX         
" vs "AUX     XYZ" and... well, the lazyness argument again.

-- 
Gabriel Genellina




More information about the Python-list mailing list