🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.os2.programmer
Article #2146

.LONGNAME Standard Extended Attribute

#2146
From: Orville R. Weyrich
Date: Sun, 27 Sep 1992 06:02
67 lines
3405 bytes
Well, I finally  got my copy of the OS/2  technical library [after  waiting
almost  2  months, I called  IBM and they Fed-ex'ed  it to me the next  day  --
I don't know what the  delay had been].

So  I started  reading. And  on page 5-12 of OS/2 2.0 Programming  Guide  -- 
Volume  I there is  a  paragaph that says:

	When an application attempts to write a  file  with a  long file
	name to  a  file system  that  does not support long  names, it 
	must generate a  short name for the file. The application should
	notify the user of the new short name and save the  original
	(long) name in the .LONGNAME extended attribute.

Now one of the "advantages" that NT advocates claim for NT is that its file
system does this  sort of mapping.  OS/2 applications do not [to my knowledge]
make full use of  this extended attribute. Are they just broken, or is there
a reason why DosFindFirst, DosFindNext and DosOpen don't check the .LONGNAME
extended attribute? Or  alternatively,  why a .SHORTNAME  extended  attribute
couldn't  be introduced?

I realize that there  would be some performance penalty from such a process,
but it shouldn't be too difficult to set  up a mapping function that [for
example] maps  long file  names to something like

	ttt'nnnh.hhh

where:

	ttt represents the first three characters after the last "." in the
		long  file name

	nnn represents the first three characters of the long file name

	' represents a flag that signals that the file name might have a
		long file  name attribute

	h.hhh are hash characters that are  generated to make the mapped
		names unique.

DOS  programs would see only the hashed names -- but would see them all.

OS/2 programs  would see  all file names in their expanded forms.

Wild-card searches of the form nnn*.ttt would be slightly slower, since the
candidates could be quickly found by looking for files with 8.3 names
matching nnn*.ttt and ttt'nnn*.*, and then the candidates would have to be
screened by looking at the .LONGNAME EA.

Wild  card searches like ???xxxxx.??x would be relatively slower, because the
mapped form ??x'???*.* admits  a much larger percentage of candidates that
need  to have their  EA's checked.

It seems that  this sort of thing could actually be implemented today strictly
at the application level, as long as a standard existed that cooperating
applications could use in generating the hashed names and deciphering them.

Anyone have any thoughts on this?:


orville

--------------------------------------   **************************************
Orville R. Weyrich, Jr.                        Weyrich Computer Consulting
Certified Data Processor                     POB 5782, Scottsdale, AZ 85261
Certified Systems Professional                   Voice: (602) 391-0821
Certified Computer Programmer            Internet: orville%weyrich@uunet.uu.net
--------------------------------------   **************************************
Technical Details
Message-ID: <1992Sep27.060222.467@weyrich.UUCP>
Path: arc1-ca.pugleaf.net!sparky!uunet!weyrich!orville

Show Full Headers
Complete Article Headers
Newsgroups: comp.os.os2.programmer
Path: arc1-ca.pugleaf.net!sparky!uunet!weyrich!orville
From: orville%weyrich@uunet.uu.net (Orville R. Weyrich)
Subject: .LONGNAME Standard Extended Attribute
Message-ID: <1992Sep27.060222.467@weyrich.UUCP>
Sender: orville@weyrich.UUCP (Orville R. Weyrich)
Reply-To: uunet.uu.net!weyrich!orville
Organization: Weyrich Computer Consulting
Date: Sun, 27 Sep 92 06:02:22 GMT
Lines: 67