Browse Prior Art Database

Directory structure in a server managing subscribers

IP.com Disclosure Number: IPCOM000016122D
Original Publication Date: 2002-Sep-25
Included in the Prior Art Database: 2003-Jun-21
Document File: 4 page(s) / 73K

Publishing Venue

IBM

Abstract

A method is disclosed that address a directory structure in a server managing subscribers.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 4

Directory structure in a server managing subscribers

A method is disclosed that address a directory structure in a server managing subscribers.

In a server managing up to several millions of subscribers, subscribers data may be stored in folders. In such case, the constraints are as follows: being able to increase the server storage capacity without any service disruption. respect when necessary any operating system constraint dealing with the maximum number of files and folders allowed under a given folder.

Those constraint deal with the way the subscribers are structured.

The following description solves those two constraint, thus allowing any server to be scalable depending on the amount of subscribers they have to manage. The server may then be housed by one up to as many machines as needed to store the data, without the need of any network dispatching capability. Whenever the need changes, the configuration is changed accordingly without any service disruption.

METHODOLOGY DESCRIPTION:

One directory per letter:

The methodology principle consists of creating a parent directory for each letter constituting the subscriber name in the server. For instance, a subscriber named johndoe will be created a directory named j/o/h/n/d/o/e/johndoe.

Maximum parent directory tree:

It becomes obvious that applying above methodology to any subscriber name regardless of its length would lead to a non managable directory structure. Therefore, a constraint is applied to this methodology, the maximum number of allowed parent directories. Hence, in previous example, say it is decided to limit the amount of parent directories to 5, johndoe's directory will be j/o/h/n/d/johndoe. On the other hand, a subscriber named hal would still have h/a/l/hal as a directory.

Handling special characters:

Special characters may be part of 3 categories, whose content depends on the used operating system:

Those accepted in a directory name: For instance, Windows some accepted characters are the alpha-numeric ones, or one of the following: _&éèà#'(-_çà)= ~#{[`^@]}$£¤µù%!ยง;,

Those accepted but mute in a letter directory name:

1

Page 2 of 4

For instance, one Windows mute character is . (the dot)

Those not allowed in a directory name: For instance, Windows forbidden characters are: \*/?<>":

The described methodology then leads to forbid in a subscriber name any character of the third category. When a subscriber name character belongs to the first category, it will naturely lead to the creation, if necessary, of the corresponding letter directory. When such character belong to the second category, it wil natureley lead to no directory creation.

For instance, subscriber named john.doe in a server whose maximum is 5 will have their data in directory j/o/h/n/john.doe. Note that the dot of john.doe did not create any letter directory named ".", yet it counted as a character in the maximum amount of allowed parent letter directories.

METHODOLOGY APPLICATIONS:

Letter directori...