Article View: comp.os.os2.programmer
Article #2146.LONGNAME Standard Extended Attribute
From: Orville R. Weyrich
Date: Sun, 27 Sep 1992 06:02
Date: Sun, 27 Sep 1992 06:02
67 lines
3405 bytes
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!orvilleShow 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