/*
* CDDL HEADER START
*
* The contents of this file are subject to the terms of the
* Common Development and Distribution License (the "License").
* You may not use this file except in compliance with the License.
*
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
* See the License for the specific language governing permissions
* and limitations under the License.
*
* When distributing Covered Code, include this CDDL HEADER in each
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
* If applicable, add the following below this CDDL HEADER, with the
* fields enclosed by brackets "[]" replaced with your own identifying
* information: Portions Copyright [yyyy] [name of copyright owner]
*
* CDDL HEADER END
*/
/*
* Copyright 2008 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*/
#ifndef _SYS_FS_PC_DIR_H
#define _SYS_FS_PC_DIR_H
#pragma ident "%Z%%M% %I% %E% SMI"
#ifdef __cplusplus
extern "C" {
#endif
struct pctime {
};
/*
* Shifts and masks for time and date fields, in host byte order.
*/
#define SECSHIFT 0
#define DAYSHIFT 0
struct pcdir {
union {
} un;
};
#ifdef __cplusplus
}
#endif
#ifdef __cplusplus
extern "C" {
#endif
/*
* Long filename support (introduced by Windows 95) is an interesting
* exercise in compatibility. Basically, it is now no longer the case
* that an entry in a directory (as described by the 'pcdir' structure above)
* contains the entire name of a file. Now, a directory entry can consist of
* a long filename component (a series of 'pcdir'-like structures) followed
* by a short filename (the old form). Each long filename component is
* identified by having it's Read-Only, Hidden, System, and Volume Label
* attributes set. Each can store 13 Unicode characters (16-bits, of
* which we only look at the lower 8 for now), broken into (gak) three
* sections of the entry (since that's the way the available bits fall out).
* In addition, each long filename entry has a sequence number (starting
* from 1). The first entry has bit 7 (0x40) set in the sequence number, and
* has the maximum value in the sequence. This may seem a bit backwards, and
* it gets worse: the first entry stores the last component of
* the name. So the directory entry for a file named
* "This is a very long filename indeed" might look like this:
*
* Offset Sequence Component Attributes Cluster Size
* 0 0x43 "me indeed" RSHV 0 0
* 32 0x02 "y long filena" RSHV 0 0
* 64 0x01 "This is a ver" RSHV 0 0
* 96 ---- "THISIS~1.TXT" <whatever> 2122 110
*
* The last entry is for the short filename, which stores actual information
* about the file (like type, permissions, cluster, and size). The short name
* is also used by non-long-filename aware applications (like Windows 3.X and
* DOS). This name is generated by Windows 95 (and now Solaris) from the
* long name, and must (of course) be unique within the directory.
* Solaris continues to this entry to actually identify the file and its
* attributes (filenames only really matter when names are used, like at
* they aren't used).
*
* Long filenames can also be broken by applications that don't
* understand them (for example, a Solaris 2.5.1 user could rename
* "THISIS~1.TXT" to "test.exe"). This can be detected because each long
* filename component has a checksum which is based on the short filename.
* After reading the long filename entry, if the checksum doesn't match the
* short name that follows, we simply ignore it and use the short name.
*
* One subtle thing - though long file names are case-sensitive,
* searches for them are not.
*
* Another _very_ subtle thing. The number of characters in the
* last long filename chunk (the first entry, with the 0x40 bit set) is
* either all the characters (if there is no null, '\0'), or all the
* characters up to the null. _However_, if the remaining characters are
* null, Norton Disk Doctor and Microsoft ScanDisk will claim
* that the filename entry is damaged. The remaining bytes must actually
* contain 0xff (discovered with Disk Doctor).
*
* Some information about long filename support can be found in the
* book "Inside Windows 95" by Adrian King.
*/
/*
* The number of bytes in each section of the name in a long filename
* entry. This is _bytes_, not characters: each character is actually
* 16 bits.
*/
/*
* A long filename entry. It must match the 'pcdir' structure in size,
* and pcdl_attr must overlap pcd_attr.
*/
struct pcdir_lfn {
/* last has bit 7 (0x40) set */
/* based on the short name */
};
/*
* FAT LFN entries are consecutively numbered downwards, and the last
* entry of a LFN chain will have the 0x40 'termination' marker logically
* or'ed in. The entry immediately preceeding the short name has number 1,
* consecutively increasing. Since the filename length limit on FAT is
* 255 unicode characters and every LFN entry contributes 13 characters,
* the maximum sequence number is 255/13 + 1 == 20.
*/
#define PCDL_LFN_VALID_ORD(x) \
#define PCDL_IS_LFN(x) \
(enable_long_filenames && \
PCDL_LFN_VALID_ORD((x)))
/*
* The first char of the file name has special meaning as follows:
*/
/*
* File attributes.
*/
/*
* Avoid hidden files unless the private variable is set.
* Always avoid the label.
*/
/*
* slot structure is used by the directory search routine to return
* the results of the search. If the search is successful sl_blkno and
* sl_offset reflect the disk address of the entry and sl_ep points to
* the actual entry data in buffer sl_bp. sl_flags is set to whether the
* entry is dot or dotdot. If the search is unsuccessful sl_blkno and
* sl_offset points to an empty directory slot if there are any. Otherwise
* it is set to -1.
*/
struct pcslot {
};
/*
* A pcfs directory entry. Directory entries are actually variable
* length, but this is the maximum size.
*
* This _must_ match a dirent64 structure in format.
* d_name is 512 bytes long to accomodate 256 UTF-16 characters.
*/
struct pc_dirent {
};
/*
* Check FAT 8.3 filename characters for validity.
* Lacking a kernel iconv, codepage support for short filenames
* is not provided.
* Short names must be uppercase ASCII (no support for MSDOS
* codepages right now, sorry) and may not contain any of
* *+=|\[];:",<>.?/ which are explicitly forbidden by the
* FAT specifications.
*/
#define pc_invalchar(c) \
(((c) >= 'a' && (c) <= 'z') || \
(c) == '"' || (c) == '*' || (c) == '+' || (c) == ',' || \
(c) == '.' || (c) == '/' || (c) == ':' || (c) == ';' || \
(c) == '<' || (c) == '=' || (c) == '>' || (c) == '?' || \
(c) == '[' || (c) == '|' || (c) == ']' || (c) == '\\')
#ifdef _KERNEL
/*
* users may give and get names in lower case, but they are stored on the
* disk in upper case to be PCDOS compatible.
* These would better come from some shared source in <sys/...> but
* there is no such place yet.
*/
extern int pc_valid_lfn_char(char); /* valid long filename ch */
extern int pc_match_short_fn(struct pcnode *, char *,
extern uchar_t pc_checksum_long_fn(char *, char *);
extern void set_long_fn_chunk(struct pcdir_lfn *, char *, int);
extern int pc_valid_long_fn(char *, int);
extern int pc_extract_long_fn(struct pcnode *, char *,
extern int pc_fname_ext_to_name(char *, char *, char *, int);
/*
* Private tunables
*/
/*
* Use long filenames (Windows 95). Disabling this causes pcfs
* to not recognize long filenames at all, which may cause it to
* break associations between the short and long names. This is likely
* to leave unused long filename entries in directories (which may make
* apparently empty directories unremovable), and would require a fsck_pcfs
* to find and fix (or a Windows utility like Norton Disk Doctor or
* Microsoft ScanDisk).
*/
extern int enable_long_filenames; /* default: on */
#endif
#ifdef __cplusplus
}
#endif
#endif /* _SYS_FS_PC_DIR_H */