OPERATION METHOD OF ELECTRONIC DEVICE FOR FILE SEARCH, AND ELECTRONIC DEVICE THEREOF

An electronic device in an example embodiment may include a communication interface configured to receive an original file, a memory, and a processor. The processor may generate bit information corresponding to uppercase and lowercase letters included in a filename of the original file. The processor may generate a case insensitive (CI) filename in which the filename of the original file is expressed by characters of a first type. The processor may encrypt the CI filename and may calculate a first hash value corresponding to the encrypted CI filename. The processor may record filename metadata including at least one of the encrypted CI filename, a length of the encrypted CI filename, the first hash value, and the bit information, in the memory. The processor may search for a target file to be found based on the filename metadata.

BACKGROUND

Technical Field

Certain example embodiments relate to an operating method of an electronic device for file search and/or such an electronic device.

Description of Related Art

Typically, a method of handling a filename by a file system may be divided into two types. One of them is a case exact (CE) method of distinguishing between uppercase and lowercase letters and recognizing as different files when uppercase and lowercase letters of a filename are different, and the other one is a case insensitive (CI) method of recognizing as a same file without distinguishing between uppercase and lowercase letters when uppercase and lowercase letters of a filename are different. For example, when a file system of a mobile device encrypts a filename to protect a user file recorded in a permanent storage device, a method and a processing operation of the file system may vary by comparing a filename according to a method of handling the filename.

SUMMARY

For example, to compare filenames processed in a case insensitive (CI) manner, a process of converting a filename of an original file into characters of one type, such as lowercase letters or uppercase letters, may be performed. In addition, to compare filenames encrypted in the CI manner, a decryption process may be performed. When processing a filename in the CI manner, a cost may increase because many processing resources are used for conversion and comparison of filenames, and thus, the cost may be reduced by using a hash value while search performance of an encrypted file may be improved.

Since a typical file system consistency verification is conducted in a state in which an encryption key is not input, the corruption of a hash value may not be determined when filename decryption is required to calculate the hash value. Therefore, verification of the hash value may be skipped. When the hash value is corrupted, even though an actual file is stored in a storage, data may be lost because the file may not be permanently found. In addition, when a collision among hash values frequently occurs, encryption for an on disk filename, which is an encrypted name for a case exact (CE) filename, and CI filename conversion may be iteratively performed.

Various example embodiments may calculate a hash value with a filename stored in an on-disk without an encryption key by using a hash value for an encrypted CI filename of an original file.

Various example embodiments may detect corruption of a hash value for a filename without an encryption key by using a hash value for an encrypted CI filename of an original file and may reconstruct a corrupted hash value.

According to an example embodiment, an electronic device may include a communication interface, comprising communication circuitry, configured to receive an original file, a memory, and at least one processor comprising processing circuitry, wherein the at least one processor is individually and/or collectively configured to generate bit information corresponding to uppercase and lowercase letters included in a filename of the original file, generate a case insensitive (CI) filename in which the filename of the original file is expressed by characters of a first type, encrypt the CI filename, calculate a first hash value corresponding to the encrypted CI filename, record filename metadata including at least one of the encrypted CI filename, a length of the encrypted CI filename, the first hash value, and the bit information, in the memory, and search for a target file to be found based on the filename metadata.

According to an example embodiment, a method of operating an electronic device may include generating bit information corresponding to uppercase and lowercase letters included in a filename of an original file, generating a CI filename in which the filename of the original file is expressed by characters of a first type, encrypting the CI filename, calculating a first hash value corresponding to the encrypted CI filename, recording filename metadata including at least one of the encrypted CI filename, a length of the encrypted CI filename, the first hash value, and the bit information, in a memory, and searching for a target file to be found based on the filename metadata.

Effects

An electronic device according to an example embodiment may reconstruct an original filename by separately storing the original filename into a CI filename and bit information corresponding to uppercase and lowercase letters included in the original filename as well as may improve search performance and reliability as shown below.

An electronic device according to an example embodiment may improve the search performance without an additional decryption cost when hash values collide.

An electronic device according to an example embodiment may guarantee the search performance for a filename by using a hash value for an encrypted CI filename of an original file.

An electronic device according to an example embodiment may detect corruption of a hash value included in filename metadata by calculating a hash value with an encrypted CI filename stored in a storage device without an encryption key and may recover the corrupted hash value.

An electronic device according to an example embodiment may detect corruption of a hash value without performing a decryption process through a key value for a filename of an original file by storing uppercase and lowercase letter information about the filename of the original file separately from the filename and may improve reconstruction stability by recovering the corrupted hash value.

In addition, various effects directly or indirectly ascertained through the present disclosure may be provided.

DETAILED DESCRIPTION

Hereinafter, example embodiments will be described in detail with reference to the accompanying drawings. When describing the embodiments with reference to the accompanying drawings, like reference numerals refer to like elements and a repeated description related thereto will be omitted.

The program140may be stored as software in the memory130and may include, for example, an operating system (OS)142, middleware144, or an application146.

The haptic module179may convert an electric signal Into a mechanical stimulus (e.g., a vibration or a movement) or an electrical stimulus which may be recognized by a user via his or her tactile sensation or kinesthetic sensation. According to an example embodiment, the haptic module179may include, for example, a motor, a piezoelectric element, or an electric stimulator.

The camera module180may capture a still image and moving images. According to an example embodiment, the camera module180may include one or more lenses, image sensors, ISPs, or flashes.

The power management module188may manage power supplied to the electronic device101. According to an example embodiment, the power management module188may be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

The battery189may supply power to at least one component of the electronic device101. According to an example embodiment, the battery189may include, for example, a primary cell which is not rechargeable, a secondary cell which is rechargeable, or a fuel cell.

According to an example embodiment, the antenna module197may form a mm Wave antenna module. According to an example embodiment, the mmWave antenna module may include a PCB, an RFIC disposed on a first surface (e.g., a bottom surface) of the PCB or adjacent to the first surface and capable of supporting a designated a high-frequency band (e.g., a mm Wave band), and a plurality of antennas (e.g., array antennas) disposed on a second surface (e.g., a top or a side surface) of the PCB, or adjacent to the second surface and capable of transmitting or receiving signals in the designated high-frequency band.

FIG.2is a block diagram200illustrating a program140according to an example embodiment. According to an example embodiment, the program140may include an OS142to control one or more resources of the electronic device101, middleware144, or an application146executable in the OS142. The OS142may include, for example, Android™, iOS™, Windows™, Symbian™, Tizen™, or Bada™. At least part of the program140, for example, may be pre-loaded on the electronic device101during manufacture, or may be downloaded from or updated by an external electronic device (e.g., the electronic device102or104, or the server108) during use by a user.

The OS142may control management (e.g., allocation or deallocation) of one or more system resources (e.g., a process, a memory, or a power source) of the electronic device101. The OS142may additionally or alternatively include at least one other drive program to drive other hardware devices of the electronic device101, for example, the input module150, the sound output module155, the display module160, the audio module170, the sensor module176, the interface177, the haptic module179, the camera module180, the power management module188, the battery189, the communication module190, the SIM196, or the antenna module197.

The middleware144may provide various functions to the application146such that a function or information provided from one or more resources of the electronic device101may be used by the application146. The middleware144may include, for example, an application manager201, a window manager203, a multimedia manager205, a resource manager207, a power manager209, a database manager211, a package manager213, a connectivity manager215, a notification manager217, a location manager219, a graphic manager221, a security manager223, a telephony manager225, or a voice recognition manager227.

The application manager201may, for example, manage the life cycle of the application146. The window manager203, for example, may manage one or more graphical user interface (GUI) resources that are used on a screen. The multimedia manager205, for example, may identify one or more formats to be used to play media files, and may encode or decode a corresponding one of the media files using a codec appropriate for a corresponding format selected from the one or more formats. The resource manager207, for example, may manage the source code of the application146or a memory space of the memory130. The power manager209, for example, may manage the capacity, temperature, or power of the battery189, and may determine or provide related information to be used for the operation of the electronic device101based on at least in part on corresponding information of the capacity, temperature, or power of the battery189. According to an example embodiment, the power manager209may interwork with a basic input/output system (BIOS) (not shown) of the electronic device101.

The database manager211, for example, may generate, search, or change a database to be used by the application146. The package manager213, for example, may manage installation or update of an application that is distributed in the form of a package file. The connectivity manager215, for example, may manage a wireless connection or a direct connection between the electronic device101and the external electronic device. The notification manager217, for example, may provide a function to notify a user of an occurrence of a specified event (e.g., an incoming call, a message, or an alert). The location manager219, for example, may manage location information on the electronic device101. The graphic manager221, for example, may manage one or more graphic effects to be offered to a user or a user interface related to the one or more graphic effects.

The security manager223, for example, may provide system security or user authentication. The telephony manager225, for example, may manage a voice call function or a video call function provided by the electronic device101. The voice recognition manager227, for example, may transmit use's voice data to the server108, and may receive, from the server108, a command corresponding to a function to be executed on the electronic device101based on at least in part on the voice data, or text data converted based on at least in part on the voice data. According to an example embodiment, the middleware144may dynamically delete some existing components or add new components. According to an example embodiment, at least part of the middleware144may be included as part of the OS142or may be implemented as another software separate from the OS142.

The application146may include, for example, a home251, dialer253, short message service (SMS)/multimedia messaging service (MMS)255, instant message (IM)257, browser259, camera261, alarm263, contact265, voice recognition267, email269, calendar271, media player273, album275, watch277, health279(e.g., for measuring the degree of workout or biometric information, such as blood sugar), or environmental information281(e.g., for measuring air pressure, humidity, or temperature information) application. According to an example embodiment, the application146may further include an information exchanging application (not shown) that is capable of supporting information exchange between the electronic device101and the external electronic device. The information exchange application, for example, may include a notification relay application adapted to transfer designated information (e.g., a call, message, or alert) to the external electronic device or a device management application adapted to manage the external electronic device. The notification relay application may transfer notification information corresponding to an occurrence of a specified event (e.g., receipt of an email) at another application (e.g., the email application269) of the electronic device101to the external electronic device. Additionally or alternatively, the notification relay application may receive notification information from the external electronic device and provide the notification information to a user of the electronic device101.

The device management application may control the power (e.g., turn-on or turn-off) or the function (e.g., adjustment of brightness, resolution, or focus) of an external electronic device that communicates with the electronic device101, or some component (e.g., a display module or a camera module of the external electronic device) of the external electronic device. The device management application may additionally or alternatively support the installation, deletion, or update of an application being operated on an external electronic device.

It should be appreciated that embodiments of the disclosure and the terms used therein are not intended to limit the technological features set forth herein to particular embodiments and include various changes, equivalents, or replacements for a corresponding embodiment. In connection with the description of the drawings, like reference numerals may be used for similar or related components. It is to be understood that a singular form of a noun corresponding to an item may include one or more of the things, unless the relevant context clearly indicates otherwise. As used herein, ““A or””, ““at least one of A and””, ““at least one of A or””, ““A, B or””, ““at least one of A, B and””, and ““A, B, or C”” each of which may include any one of the items listed together in the corresponding one of the phrases, or all possible combinations thereof. Term” such as “first”, “second”, or “first” or “second” may simply be used to distinguish the component from other components in question, and may refer to components in other aspects (e.g., importance or order) is not limited. It is to be understood that if an element (e.g., a first element) is referred to, with or without the term ““operativel”” or ““communicativel””, as ““coupled with”” ““coupled to”” ““connected with”” or ““connected to”” another element (e.g., a second element), it means that the element may be coupled with the other element directly (e.g., wiredly), wirelessly, or via at least a third element(s).

As used in connection with embodiments of the disclosure, the term ““module”” may include a unit implemented in hardware, software, or firmware, and may interchangeably be used with other terms, for example, ““logic”” ““logic block”” ““part”” or ““circuitry”” A module may be a single integral component, or a minimum unit or part thereof, adapted to perform one or more functions. For example, according to an embodiment, the module may be implemented in a form of an application-specific integrated circuit (ASIC). Thus, each “module” herein may comprise circuitry.

FIG.3is a block diagram illustrating an electronic device according to an example embodiment. Referring toFIG.3, an electronic device300(e.g., the electronic device101ofFIG.1) according to an example embodiment may include a communication interface310(e.g., the communication module190ofFIG.1), a processor330(e.g., the processor120ofFIG.1), and a memory350(e.g., the memory130ofFIG.1). The communication interface310, the processor330, and the memory350may be connected, directly or indirectly, via a communication bus (not shown).

The communication interface310may receive an original file. The original file may be, for example, a file to be stored in the memory350or a storage device (e.g., a storage device670ofFIG.6) through a file system (e.g., a file system ofFIG.6) included by an OS (e.g., the OS142ofFIGS.1and2) of the electronic device300or a file to be searched for or to be verified. However, the example is not limited thereto.

The processor330may generate bit information corresponding to uppercase and lowercase letters included in a filename of the original file. For example, the processor330may generate the bit information by allocating a first bit value in correspondence to a position of an uppercase letter included in the filename of the original file and allocating a second bit value in correspondence to a position of a lowercase letter included in the filename of the original file. For example, the first bit value may be “ ” “ ” and the second bit value may be “ ” “ ”. Also conversely, the first bit value may be “ ” “ ” and the second bit value may be “ ” “ ”. Hereinafter, for ease of description, the filename of the original file may be referred to as an ““original filenam””.

The processor330may generate a case insensitive (CI) filename that represents the filename of the original file as characters of a first type. The characters of the first type may include, for example, one of uppercase letters and lowercase letters. In this case, the ““CI filenam”” may be a filename in which the original filename is converted into character strings in one type, such as an uppercase letter and a lowercase letter.

The processor330may encrypt the CI filename. The processor330may encrypt the CI filename by various known encryption algorithms. The encryption algorithm may include, for example, a block encryption algorithm and a stream encryption algorithm. However, the example is not limited thereto.

The processor330may calculate a first hash value corresponding to the encrypted CI filename. For example, the first hash value may be calculated by a first hash function. The ““hash functio”” may be a function that maps data having an arbitrary length to data of a fixed length. The hash function may be referred to as a ““hash algorith”” or a ““hash generato””.

Each “processor” herein includes processing circuitry, and/or may include multiple processors. For example, as used herein, including the claims, the term “processor” may include various processing circuitry, including at least one processor, wherein one or more of at least one processor, individually and/or collectively in a distributed manner, may be configured to perform various functions described herein. As used herein, when “a processor”, “at least one processor”, and “one or more processors” are described as being configured to perform numerous functions, these terms cover situations, for example and without limitation, in which one processor performs some of recited functions and another processor(s) performs other of recited functions, and also situations in which a single processor may perform all recited functions. Additionally, the at least one processor may include a combination of processors performing various of the recited/disclosed functions, e.g., in a distributed manner. At least one processor may execute program instructions to achieve or perform various functions.

In this case, a value of original data before hash mapping may be referred to as a““ke”” and a value of data after mapping may be referred to as a““hash valu””. For example, the ““hash valu”” may correspond to a value of data of a fixed length calculated by applying the hash function. The hash function may be of various types and each hash function may have a different length of a hash value. The hash value may be referred to as hash code or a hash sum.

The processor330may record filename metadata Iding at least one of the encrypted CI filename, the length of the encrypted CI filename, the first hash value, and the bit information, in the memory350. A process of recording a filename by the processor330and an embodiment of searching for a filename are further described with reference toFIG.4.

For example, the processor330may record the filename metadata in different metadata areas in the memory350by attribute or item or may store the filename metadata in the same metadata area in the memory350. Hereinafter, the memory350may be, for example, a certain storage space of the memory350provided for a file system and may be collectively construed as a separate storage device, such as a cloud server or an external hard drive. An embodiment of the file system is further described with reference toFIG.6below.

For example, from the filename metadata, the processor330may record the encrypted CI filename, the length of the encrypted CI filename, and the first hash value in a directory entry area of the original file. In addition, from the filename metadata, the processor330may separately record the bit information in a space (e.g., an i-node space) for storing a file attribute of the original file or an extra attributes space. An embodiment of the space for storing a file attribute or the extra attributes space is further described with reference toFIG.5below.

The processor330may search for a target file to be found based on the filename metadata recorded in the memory350. In this case” the “me” adata” may correspond to information accompanying data to analyze and classify structured information about the data and add additional information, and may be, for example, data for data.” The “filename me” adata” may be construed as data assigned to a filename according to a predetermined rule to efficiently find and use the filename. An example of the filename metadata is further described with reference toFIG.8Abelow. The processor330may generate a second CI filename in which a filename of a target file is expressed by characters of the first type. The processor330may encrypt the second CI filename. The processor330may calculate a second hash value corresponding to the encrypted second CI filename. The processor330may perform a first comparison whether the first hash value coincides with the second hash value. The processor330may search for the target file based on a first comparison result.

For example, when the first comparison result coincides, the processor330may perform a second comparison of a filename length and a character string between the encrypted CI filename recorded in the memory350and the encrypted second CI filename. The processor330may search for the target file based on a second comparison result. For example, when the second comparison result coincides, the processor330may reconstruct the filename of the original file. When the second comparison result coincides, the processor330may reconstruct the filename of the original file by converting a character of the CI filename corresponding to an order of bits included in the bit information into an uppercase letter or a lowercase letter according to the bit information.

On the other hand, when the second comparison result does not coincide, the processor330may iteratively compare whether hash values corresponding to remaining filenames stored in the memory350coincide with the second hash value. When the second comparison result does not coincide, the processor330may iteratively compare whether the hash values coincide. When a third hash value, which is one of the hash values, coincides with the second hash value, the processor330may perform a third comparison of a filename length and a character string between an encrypted third CI filename corresponding to the third hash value and the encrypted second CI filename. Various embodiments of a method of searching for a search file by the processor330are further described with reference toFIGS.9and10below.

The memory350may store filename metadata generated by the processor330. In this case, the filename metadata may correspond to the original file received through the communication interface310.

In addition, the processor330may perform at least one method described with reference toFIGS.1to11or a scheme corresponding to the at least one method. The processor330may be a hardware-implemented optimization device having a physically structured circuit to execute desired operations. For example, the desired operations may include code or instructions in a program. The hardware-implemented electronic device300may include, for example, a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), a processor core, a multi-core processor, a multiprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and a neural processing unit (NPU).

The memory350may store at least one program. The memory350may store a variety of information generated from processing by the processor330. In addition, the memory350may store a variety of data and programs. The memory350may include, for example, a volatile memory (e.g., the volatile memory132ofFIG.1) or a non-volatile memory (e.g., the non-volatile memory134ofFIG.1). The memory350may include a high-capacity storage medium such as a hard disk to store a variety of data.

FIGS.4A to4Care diagrams illustrating a process of storing a filename and a process of searching for a file name according to an example embodiment.

Referring toFIG.4A, a process in which a typical file system stores a filename of which uppercase and lowercase letters are distinguished is illustrated. For example, a fil “name “Hello” onkey” of an original file may be encrypted and stored and a hash value (“.g., “ ” x1234”) may be calculated by applying a hash function to a fil “name “hello” onkey” obtained by converting the fil “name “Hello” onkey” of the original file into lowercase letters. In this case, the fil “name “Hello” onkey” of the original file may be encrypted as a character string (“.g., “x@3?ei #45k”v9p*c”). In addition, after the fil “name “Hello” onkey” of the original file is converted into lowercase le“ters “hello” onkey”, the hash value (“.g., “ ” x1234”) corresponding to the lowercase le “ters “hello” onkey” may be calculated.

In this case, since a hash value of the encrypted character string (“.g., “x@3?ei #45k”v9p*c”) of the original file is different from a hash value of the lowercase le “ters “hello” onkey”, the hash value of the lowercase fil“name “hello” onkey” of the original file may not be calculated without a key of the filename of the original file. For example, without the key value of the filename of the original file, corruption of the hash value may not be detected or the filename of the original file may not be reconstructed.FIG.4Billustrates a case in which an electronic device (e.g., the electronic device101ofFIG.1and the electronic device300ofFIG.3) according to an example embodiment converts a filename (“.g., “Hello” onkey”) of an original file into lowercase letters (“.g., “hello” onkey”) and separately stores uppercase and lowercase letter information (“.g., “10000”00000”) corresponding to the filename converted into lowercase letters (“.g., “hello” onkey”) from the filename.

The electronic device300may obtain an encrypted character string (“.g., “qwc?{circumflex over ( )}xto&o”p % % de”) by performing encryption on the lowercase letters (“.g., “hello” onkey”) and may calculate a hash value (“.g., “ ” x1234”) for the encrypted character s“ring “qwc?{circumflex over ( )}xto&o”p % % de”. In this case, the hash value may be a hash value for an encrypted character string converted into lowercase letters and information about uppercase and lowercase letters of the filename of the original file may be separately stored. The electronic device300may obtain a filename converted into lowercase letters through a decryption process using a key (e.g., fname_key) value of the filename and may reconstruct the filename converted into lowercase letters to the filename of the original file by the uppercase and lowercase letter information.

FIG.4Cillustrates a case in which the electronic device300according to an example embodiment reconstructs a filename (“.g., “hello” onkey”) expressed by lowercase letters by decrypting an encrypted character string (“.g., “qwc?{circumflex over ( )}xto&o”p % % de”) using a key (e.g., fname_key) value of the filename.

The electronic device300may determine whether a file to be found (searched for) is searched by reconstructing a filename (“.g., “Hello” onkey”) of an original file by reflecting uppercase and lowercase letter information (“.g., “10000”00000”) stored separately from the filename in a fil “name “hello” onkey” expressed by lowercase letters.

In an example embodiment, by storing the uppercase and lowercase letter information about the filename of the original file separately from the filename, the search performance may be improved by searching for a filename without distinguishing between uppercase and lowercase letters in an environment where encryption of a filename is performed to protect a user file recorded in a memory (e.g., the memory130ofFIG.1, the memory350ofFIG.3, and a storage device670ofFIG.6) of the electronic device300.

In addition, in an example embodiment, by storing the uppercase and lowercase letter information about the filename of the original file separately from the filename, corruption of the hash value may be detected without performing a decryption process through a key value with respect to the filename of the original file and the reconstruction stability may be improved by recovering the corrupted hash value.

FIG.5is a diagram illustrating a structure of a file according to an example embodiment. Referring toFIG.5, a hierarchical structure500of a file in an example embodiment is illustrated.

A processing process in an OS (e.g., the OS142ofFIGS.1and2) of an electronic device (e.g., the electronic device101ofFIG.1and the electronic device300ofFIG.3) according to an example embodiment may be, for example, configured in the unit of file. The file may have, for example, a characteristic of the hierarchical structure500ofFIG.5.

The file may include, for example, a filename510, an i-node space520, and a data block530. The filename510may correspond to an element required for a user to distinguish, access, and manipulate a file. As a hardware device is managed by a file, all processing processes in an OS may need to be processed through a single interface, which is the file. Accordingly, the filename510may need to be distinguished to handle the file. Directories corresponding to different files may be distinguished by the filename510.

The i-node space520may store an i-node. An i-node may be referred to as an index node and for example, may correspond to a data structure used in a file system shown inFIG.6below. All files and directories may each have one i-node520.

The i-node space520may be an example of a space for storing a file attribute of an original file. In this case, the file attribute may include, for example, an archive attribute, a hidden attribute, a system attribute, and a read only attribute, but the example is not limited thereto.

The archive attribute may be an attribute assigned when a file is newly generated or is changed and may be used to inform that the file is not backed up or the file is an original copy. The hidden attribute may be used to hide a file. The system attribute may be used to emphasize that the file is a system file. The read only attribute may be used to inform that only reading the file is allowed and writing, modifying, and deleting the file are not allowed.

For ease of description, in an example embodiment, a description is provided mainly based on an i-node and/or an i-node space. However, the example is not limited thereto and the file attribute of the original file may be stored in various types, such as storing in a form of a combination of a directory entry with an i-node space, such as a file allocation table (FAT) file system.

The i-node space520may describe a file, and for example, may include information, such as a data location (address) of an actual file in the data block530, a type of the file, an ownership (a user or a group) of the file, a permission of the file, an access mode of the file, and a timestamp (last modified date) of the file. However, the example is not limited thereto. The i-node space520may occupy, for example, about 1% of the total storage space.

For example, one i-node space520may be generated whenever one file is generated by a file system and an i-node number corresponding to the generated i-node space520may be assigned. The i-node number may be a unique identification number and may start from 0 for each partition. For example, the i-node space520may be generated at a location where the number of links is 0, and after storing information, a value of the link may be changed to 1. The i-node may be, for example, stored in the i-node space520, but the example is not limited thereto.

The data block530may correspond to a space in which content of an actual file is stored. For example, when a file is stored in a memory (e.g., the memory130ofFIG.1, the memory350ofFIG.3, and the storage device670ofFIG.6), data may be sequentially stored in the data block530without specific distinction. Since file data is not specifically distinguished when the file data is stored in the data block530, a method may be needed to distinguish which portion is data for which file. In this case, information indicating which portion of the data block530is data for which file may be stored in the i-node space520.

FIG.6is a block diagram illustrating a structure of a file system according to an example embodiment. Referring toFIG.6, a file system according to an example embodiment may include a filename management system600for managing a filename. In this case, for example, the file system may be included in an OS (e.g., the OS142ofFIGS.1and2) of the electronic device (e.g., the electronic device101ofFIG.1and the electronic device300ofFIG.3) described above and may be configured as a separate file.

The filename management system600may include, for example, a filename recording device610, a filename search device620, a case converter630, a hash generator640, an encryptor and decryptor650, a case bit (case_bits) generator660, and a storage device670(e.g., the memory130ofFIG.1and/or the memory350ofFIG.3). However, the example is not limited thereto.

For example, the filename management system600may request the filename recording device610to record a filename (e.g., a case exact (CE) filename) of an original file with filename metadata (e.g., filename metadata810ofFIG.8A) corresponding to the filename in the storage device670.

The filename recording device610may generate a CI filename consisting of or including lowercase letters by using the case converter630. The CI filename may be represent “d as “c” _name “.

The case converter630may convert a character string of the filename of the original file input to the filename management system600into all uppercase letters or all lowercase letters. For example, when the filename of the original fi” e is “Hello” onkey”, the case converter630may generate a CI fil” name “hello” onkey” corresponding to the fil “name “Hello” onkey” of the original file. When the filename of the original fi “e is “HELLO”onkey”, a CI fil “name “hello” onkey” corresponding to the fil “name “Hello” onkey” of the original file may be identically generated.

The hash generator640may generate a hash value corresponding to a CI filename encrypted by the encryptor and decryptor650. For example, when the hash generator640is a 16-bit hash generator, a hash value for an encrypted CI filename may be generated as a 16-bit value, such as ““x1234””. In another example, when the hash generator640is a 32-bit hash generator, a hash value for an encrypted CI filename may be generated as a 32-bit value, su “h as “0x12”45678”. The hash value may vary depending on a hash algorithm used by the hash generator640.

The encryptor and decryptor650may encrypt a character string (e.g., the CI filename) converted by the case converter630or may decrypt an encrypted character string. The CI filename encrypted by the encryptor and decryptor650may be represent “d as “en” _name”. For example, when the CI filena“e is “hello” onkey”, the encrypted CI filename may be generat“d as “qwc?{circumflex over ( )}xto&o”p % % de”. In an example embodiment, a length of a CI filename may be 11 characters and a length of an encrypted CI filename may be 16 characters. The length of the CI filename and the length of the encrypted CI filename may be the same or different from each other. The length of the encrypted CI filename may vary depending on an encryption algorithm used by the encryptor and decryptor650.

The case bit generator660may generate a state of uppercase and lowercase letters of a filename of an input original file as a bitstream. For example, the case bit generator660may convert an uppercase letter included in the filename of the input original file into ““it “1” and may convert a lowercase letter included in the filename of the original file into ““it “0”. Depending on the embodiment, the case bit generator660may convert an uppercase letter included in the filename of the input original file into ““it “O” and may convert a lowercase letter included in the filename of the original file into ““it “1”.

For example, the filename management system600may request the filename search device620to search for whether a filename, which is the same as a filename to be searched for, exists in filenames stored in the storage device670. In this case, the filename search device620may generate a CI filename (e.g., a first CI filename) using the case converter630described above, may generate an encrypted CI filename (e.g., a first encrypted CI filename) using the encryptor and decryptor650, and may generate a hash value (e.g., a first hash value) corresponding to the encrypted CI filename using the hash generator640.

The filename search device620may verify whether hash values (e.g., a second hash value or a third hash value) recorded in the storage device670coincide with a hash value (e.g., the first hash value) generated by the hash generator640. When the first hash value coincides with the second hash value, the filename search device620may compare an encrypted CI filename (e.g., enc_name, a second or third encrypted CI filename) recorded in the storage device670with the first encrypted CI filename. When the comparison result coincides, the filename search device620may reconstruct the original filename (e.g., the CE filename) in which uppercase and lowercase letters of the first CI filename are converted by using the case converter630.

When the comparison result between the first encrypted CI filename and the second encrypted CI filename does not coincide, the filename search device620may search for a file having the filename to be found by iteratively performing the process described above on all files stored in the storage device670.

FIG.7is a flowchart illustrating an operating method of an electronic device according to an example embodiment. Operations to be described hereinafter may be sequentially performed but not necessarily. For example, the order of the operations may change, and at least two of the operations may be performed in parallel.

Referring toFIG.7, an electronic device (e.g., the electronic device101ofFIG.1and the electronic device300ofFIG.3) according to an example embodiment may generate and store a target file or may search for a stored file through operations710to760.

In operation710, the electronic device300may generate bit information corresponding to uppercase and lowercase letters included in a filename (e.g., a “filename of an original file”) of an original file. For example, when a request for recording an original file in a memory (e.g., the memory130ofFIG.1, the memory350ofFIG.3, and/or the storage device670ofFIG.6) is received, the electronic device300may generate a bitstream as bit information using the case bit generator660described above, wherein the bitstream may correspond to uppercase and lowercase letters included in the filename of the original file. For example, when the filename of the original file is “HELLOmonkey”, the electronic device300may generate bit information such as a bitstream (e.g., “11111000000”) by allocating a first bit value (e.g., bit “1”) to each of the uppercase letters “HELLO” and allocating a second bit value (e.g., bit “0”) to each of the lowercase letters “monkey”. An example embodiment of a method of the electronic device300to generate bit information corresponding to uppercase and lowercase letters included in a filename of an original file is further described with reference toFIG.8Bbelow.

In operation720, the electronic device300may generate a CI filename in which the filename of the original file is expressed by characters of a first type. For example, the electronic device300may generate a CI filename corresponding to the filename of the original file, such as the case converter630described above.

For example, the characters of the first type may be “lowercase” letters. In this case, the electronic device300may generate a CI filename “hellomonkey” in which the filename “HelloMonkey” of the original file is expressed by the characters (e.g., lowercase letters) of the first type. For example, when uppercase and lowercase letters of the filename of the original file are different, such as “HELLOmonkey”, the same CI filename “hellomonkey” corresponding to the filename “HELLOmonkey” of the original file may be generated.

Depending on the embodiment, the characters of the first type may be “uppercase” letters. In this case, the electronic device300may generate a CI filename “HELLOMONKEY” in which the filename “HelloMonkey” of the original file is expressed by the characters (e.g., uppercase letters) of the first type. In another example, when the filename of the original file is “HELLOmonkey”, the CI filename may be identically generated as “HELLOMONKEY”.

In operation730, the electronic device300may encrypt the CI filename generated in operation720. For example, when the CI filename is “hellomonkey”, the encrypted CI filename may be generated as “qwc?{circumflex over ( )}xto&otp % % de”. In an example embodiment, a length of an encrypted CI filename may vary depending on an encryption algorithm used by the electronic device300.

In operation740, the electronic device300may calculate a first hash value corresponding to the encrypted CI filename (e.g., “qwc?{circumflex over ( )}xto&otp % % de”) in operation730. For example, when a hash function used by the electronic device300is a 16-bit hash function, a hash value for an encrypted CI filename may be generated as a 16-bit value, such as “0x1234”. In another example, when a hash function used by the electronic device300is a 32-bit hash function, a hash value for an encrypted CI filename may be generated as a 32-bit value, such as “0x12345678”. The first hash value calculated by the electronic device300may vary depending on a hash algorithm used by the electronic device300.

In operation750, the electronic device300may record filename metadata including at least one of the bit information generated in operation710, the encrypted CI filename and the length of the encrypted CI filename in operation730, and the first hash value calculated in operation740, in the memory. In this case, the bit information may be stored as a bitstream as shown inFIG.8Bbelow or may be stored in an encrypted form. For example, when encrypting in a 2 bit right rotate method that rotates original bit information by 2 bits in a right direction, original bit information “100001000000” may be encrypted as “001000010000”. An example of the filename metadata according to an example embodiment is further described with reference toFIG.8Abelow.

In operation760, the electronic device300may search for a target file to be found based on the filename metadata. The method of searching for a target file is further described with reference toFIG.9below.

FIG.8Ais a diagram illustrating an example of filename metadata according to an example embodiment andFIG.8Bis a diagram illustrating a method of generating bit information according to an example embodiment.

For example, it may be assumed that an electronic device (e.g., the electronic device101ofFIG.1and the electronic device300ofFIG.3) records a filename “HelloMonkey” of an original file in a memory (e.g., the memory130ofFIG.1, the memory350ofFIG.3, and the storage device670ofFIG.6). In this case, a CI filename expressed by characters (e.g., lowercase letters) of a first type may be “hellomonkey” and the CI filename may be encrypted as “qwc?{circumflex over ( )}xto&otp % % de” by an encryption algorithm.

In this case, the following information may be stored in filename metadata810recorded in the storage device670in relation to the filename of the original file. The encrypted CI filename “qwc?{circumflex over ( )}xto&otp % % de” may be stored in a filename item811of the filename metadata810and “16”, which is the length of the encrypted CI filename “qwc?{circumflex over ( )}xto&otp % % de”, may be stored in a filename length (name length) item813. “0x12345678”, which is a hash value corresponding to the encrypted CI filename, may be stored in a filename hash (name hash) item815, and bit information “10000100000” corresponding to uppercase and lowercase letters of the filename of the original file may be stored in a case bit item817.

An example embodiment of a method of converting bit information stored in the case bit item817is further described with reference toFIG.8Bbelow.

To summarize, the filename metadata as810, such [qwc?{circumflex over ( )}xto&otp % % de: 16:0x12345678: 10000100000], in correspondence to the filename “HelloMonkey” of the original file may be recorded in the memory.

Alternatively, when the filename of the original file is “Welcome” or “OldAndNewWorld”, the filename metadata810, such as [r823jf@#F2903wed: 16:0x95de1509: 1000000] or [f309j882f #!%! #r112dr #!$r@ #2rwr23: 32:0x3edfe7ba: 10010010010000], may be recorded in the memory350as described above.

Depending on the embodiment, a 16-bit hash generator (e.g., the hash generator640ofFIG.6) and a case bit generator (e.g., the case bit generator660ofFIG.6) that allocates a second bit value (e.g., bit “0”) in correspondence to a position of an uppercase letter and allocates a first bit value (e.g., bit “1”) in correspondence to a position of a lowercase letter may be used. In this case, the filename metadata810, such as [qwc?{circumflex over ( )}xto&otp % % de: 16:0x1234: 01111011111], in correspondence to the filename “HelloMonkey” of the original file may be recorded in the memory350. In addition, in correspondence to the filename “Welcome” of the original file, the filename metadata810, such as [r823jf@ #F2903wed: 16:0x95de: 0111111], may be stored and in correspondence to the filename “OldAndNewWorld” of the original file, the filename metadata810, such as [f309j882f #!%! #r112dr #!$r@ #2rwr23: 32:0x3edf: 01101101101111], may be stored.

Depending on the embodiment, the electronic device300may encrypt the bit information in a 2 bit right rotate method in addition to the 16-bit hash generator640and the case bit generator660that allocates the second bit value (e.g., bit “0”) in correspondence to the position of the uppercase letter and allocates the first bit value (e.g., bit “1”) in correspondence to the position of the lowercase letter. In this case, in correspondence to the filename “HelloMonkey” of the original file, filename metadata, such as [qwc?{circumflex over ( )}xto&otp % % de: 16:0x1234: 11011110111], may be stored and in correspondence to the filename “Welcome” of the original file, filename metadata, such as [r823jf@ #F2903wed: 16:0x95de: 1101111], may be stored in the memory350. In addition, in correspondence to the filename “OldAndNewWorld” of the original file, filename metadata, such as [f309j882f #!%! #r112dr #!$r@ #2rwr23: 32:0x3edf: 11011011011011], may be stored in the memory350.

In an example embodiment, the filename metadata810may be, for example, recorded in a metadata area of the file system or in the memory350, but the example is not limited thereto.

For example, when the filename metadata810is recorded in the memory350, the filename metadata810may be recorded in the same metadata area in the file system or the memory350or the filename metadata810may be divided and recorded in different metadata areas based on each item or each attribute of the filename metadata810.

Depending on the embodiment, the filename metadata810may be recorded in a directory entry area of the file system. In this case, information corresponding to the filename item811, the filename length (name length) item813, and the filename hash (name hash) item815of the metadata810may be recorded in the directory entry area of the file system and bit information corresponding to the case bit item817may be separately recorded in a space (e.g., the i-node space520ofFIG.5) for storing a file attribute of the original file or an extra attributes space.

Referring toFIG.8B, bit information corresponding to a filename “HelloMonkey” of an original file according to an example embodiment is illustrated.

For example, when the filename of the original file is “HelloMonkey”, the electronic device300may generate bit information like a bitstream (e.g., “10000100000”) by allocating a first bit value (e.g., bit “1”) to an uppercase letter H831at a first position in the filename and an uppercase letter M835at a sixth position in the file name and allocating a second bit value (e.g., bit “0”) to lowercase letters at remaining positions. Accordingly, the bit information corresponding to the filename “HelloMonkey” of the original file may be “10000100000”.

Depending on the embodiment, the electronic device300may allocate the second bit value (e.g., bit “0”) to an uppercase letter included in the filename of the original file and may allocate the first bit value (e.g., bit “1”) to a lowercase letter. For example, when the filename of the original file is “HelloMonkey”, the electronic device300may generate bit information “01111011111” by allocating the second bit value (e.g., bit “0”) to the uppercase letters H and M and allocating the first bit value (e.g., bit “1”) to the remaining lowercase letters.

FIG.9is a flowchart illustrating a method of searching for a target file according to an example embodiment. Processes to be described hereinafter may be sequentially performed but not necessarily. For example, the order of the processes may change, and at least two of the processes may be performed in parallel.

Referring toFIG.9, an electronic device (e.g., the electronic device101ofFIG.1, the electronic device300ofFIG.3, the processor120ofFIG.1, and the processor330ofFIG.3) according to an example embodiment may search for a target file to be found through operations910to960.

In operation910, the electronic device300may generate a second CI filename in which a filename of the target file is expressed by characters of a first type. In this case, the “second CI filename” may correspond to a CI filename corresponding to the filename of the target file for which a search request is received.

In operation920, the electronic device300may encrypt the second CI filename generated in operation910.

In operation930, the electronic device300may calculate a second hash value corresponding to the second CI filename encrypted in operation920.

In operation940, the electronic device300may perform a first comparison whether the first hash value calculated in operation740described above coincides with the second hash value calculated in operation930.

In operation950, the electronic device300may search for the target file based on a first comparison result of operation940. For example, when the first comparison result coincides, the electronic device300may perform a second comparison whether file lengths and character strings of the CI filename encrypted through operation730recorded in a memory (e.g., the memory130ofFIG.1, the memory350ofFIG.3, and/or the storage device670ofFIG.6) and the second CI filename encrypted in operation920coincide with each other. The electronic device300may search for the target file based on a second comparison result.

For example, when the second comparison result coincides, the electronic device300may reconstruct the filename of the original file by converting a character of the CI filename corresponding to an order of bits included in the bit information into an uppercase letter or a lowercase letter according to the bit information. On the other hand, when the second comparison result does not coincide, the electronic device300may iteratively compare whether hash values corresponding to the remaining filenames stored in the memory350coincide with the second hash value. When a third hash value, which is one of hash values corresponding to the remaining filenames stored in the memory350coincides with the second hash value, by performing a third comparison whether filename lengths and character strings of an encrypted third CI filename corresponding to the third hash value and the encrypted second CI filename coincide, the electronic device300may iteratively compare whether the hash values corresponding to the remaining filenames coincide with the second hash value.

FIG.10is a flowchart illustrating a method of searching for a filename according to an example embodiment. Operations to be described hereinafter may be sequentially performed but not necessarily. For example, the order of the operations may change, and at least two of the operations may be performed in parallel.

Referring toFIG.10, an electronic device (e.g., the electronic device101ofFIG.1, the electronic device300ofFIG.3, the processor120ofFIG.1, and the processor330ofFIG.3) that receives a search request for whether a filename of a target file to be found exists in filenames stored in a memory (e.g., the memory130ofFIG.1, the memory350ofFIG.3, and/or the storage device670ofFIG.6) may search for a filename through operations1010to1090.

In operation1010, the electronic device300may generate a CI filename (e.g., a second CI filename) corresponding to a filename of a target file for which a search request is received. In this case, the second CI filename may express the filename of the target file by characters (e.g., lowercase letters) of a first type. For example, when the filename of the target file is “HelloMonkey”, the CI filename (e.g., the second CI filename) corresponding to the filename of the target file may be “hellomonkey” in which the filename of the target file is converted into all lowercase letters.

In operation1020, the electronic device300may encrypt the CI filename (e.g., the second CI filename) generated in operation1010, for example, like the case convertor630described above. For example, when the CI filename (e.g., the second CI filename) is “hellomonkey”, the encrypted filename (e.g., the encrypted second CI filename) may be generated as “qwc?{circumflex over ( )}xto&otp % % de”.

In operation1030, the electronic device300may generate a hash value (e.g., the second hash value) corresponding to the filename (e.g., the second CI filename) encrypted in operation1030.

In operation1040, the electronic device300may determine whether an end of a directory recorded in the memory350is reached. When it is determined that the end of the directory recorded in the memory350is reached, in operation1090, the electronic device300may output a message “file not found” to inform that the target file is not found.

When it is determined that the end of the directory recorded in the memory350is not reached in operation1040, in operation1050, the electronic device300may compare whether hash values recorded in the memory350coincide with the hash value generated in operation1030. When a comparison result of operation1050does not coincide, the electronic device300may repeat operations1050and1060until all files are searched for through operation1040.

When the comparison result of operation1050coincides, in operation1060, the electronic device300may compare whether the filename (e.g., the second CI filename) encrypted in operation1020coincides with the encrypted filename recorded in the memory350. More specifically, the electronic device300may compare whether filename lengths and character strings of the filename (e.g., the second CI filename) encrypted in operation1020and the encrypted filename recorded in the memory350coincide with each other.

When a comparison result of operation1060does not coincide, the electronic device300may repeat operations1050and1060until all files are searched for through operation1040.

When the comparison result of operation1060coincides, the electronic device300may consider that the same filename is found and in operation1070, the electronic device300may convert the CI filename generated in operation1010into a CE filename. For example, the electronic device300may reconstruct a CE filename of the original file by using the CI filename and the bit information recorded in the memory350. For example, when a CI filename “hellomonkey” and bit information “10000100000” corresponding to the CI filename are generated by allocating a first bit value (e.g., bit “1”) in correspondence to a position of an uppercase letter included in a filename of the original file “HelloMonkey” and allocating a second bit value in correspondence to a position of a lowercase letter included in the filename of the original file, the electronic device300may reconstruct the original filename “HelloMonkey” by changing h and m at positions where the bit information is “1” to H and M, respectively, and maintaining the rest in lowercase letters.

FIG.11is a flowchart illustrating a method of verifying a filename according to an example embodiment. Operations to be described hereinafter may be sequentially performed but not necessarily. For example, the order of the operations may change, and at least two of the operations may be performed in parallel.

Referring toFIG.11, an electronic device (e.g., the electronic device101ofFIG.1, the electronic device300ofFIG.3, the processor120ofFIG.1, and the processor330ofFIG.3) according to an example embodiment may verify a filename through operations1110to1150. According to an example embodiment, since a hash value may be calculated without an encryption key, the corruption of the filename may be verified by checking a hash value for a CI filename.

In operation1110, the electronic device300may verify a filename. For example, the electronic device300may verify a filename stored in a tree structure in a memory (e.g., the memory130ofFIG.1, the memory350ofFIG.3, and/or the storage device670ofFIG.6).

In operation1120, the electronic device300may determine whether an end of a directory stored in the memory350is reached. In this case, “the end of the directory stored in the memory350” may be construed as the completion of verification of all filenames stored in the memory350. When it is determined that the end of the directory is reached in operation1120, the electronic device300may terminate a verification operation.

On the other hand, when it is determined that the end of the directory is reached in operation1120, in operation1130, the electronic device300may generate a hash value for an encrypted CI filename included in filename metadata (e.g., the filename metadata810ofFIG.8A).

In operation1140, the electronic device300may check the corruption of the hash value by comparing the hash value generated in operation1130with the hash value stored in the filename metadata810. In addition, when the hash value is corrupted, the electronic device300may update the hash value stored in the filename metadata810with the hash value generated in operation1130.

In operation1150, the electronic device300may verify various feature values possessed by the file including the filename metadata810by using pre-stored file attribute information.

When the check is completed in operation1150, the electronic device300may iteratively perform verification on the corruption of the filenames stored in the memory350through operation1120.

For example, in correspondence to the original filename “HelloMonkey”, [qwc?{circumflex over ( )}xto&otp % % de: 16:0x12345678: 10000100000] may be stored as the filename metadata810in the memory350. In this case, due to 1 bit flip, a hash value “0x12345678” stored in the filename metadata810may be corrupted as “0x123456f8”. In this case, the electronic device300may calculate a hash value (e.g., “0x12345678”) for the encrypted CI filename “qwc?{circumflex over ( )}xto&otp % % de” included in the filename metadata810. The electronic device300may identify the corruption of data through a hash value check by comparing the hash value “0x12345678” for the encrypted CI filename “qwc?{circumflex over ( )}xto&otp % % de” with the corrupted hash value “0x123456f8” included in the filename metadata810. The electronic device300may prevent or reduce data loss by recovering the corrupted hash value “0x123456f8” to “0x12345678” by the calculated hash value “0x12345678”.

According to an example embodiment, the electronic device101or301may include the communication interface310, comprising communication circuitry, configured to receive an original file, the memory130,350, or670, and at least one processor120and/or330comprising processing circuitry, and the at least one processor120and/or330individually and/or collectively may generate bit information corresponding to uppercase and lowercase letters included in a filename of the original file, may generate a CI filename in which the filename of the original file is expressed by characters of a first type, may encrypt the CI filename, may calculate a first hash value corresponding to the encrypted CI filename, may record filename metadata810including at least one of the encrypted CI filename, a length of the encrypted CI filename, the first hash value, and the bit information, in the memory130,350, or670, and may search for a target file to be found based on the filename metadata.

According to an example embodiment, the processor120or330may generate the bit information by allocating a first bit value in correspondence to a position of an uppercase letter included in the filename of the original file and allocating a second bit value in correspondence to a position of a lowercase letter included in the filename of the original file.

According to an example embodiment, the characters of the first type may include one of uppercase and lowercase letters.

According to an example embodiment, the processor120or330may record the filename metadata810in a different metadata area in the memory130,350, or670based on an attribute of the filename metadata810, or may store the filename metadata810in a same metadata area in the memory130,350, or670.

According to an example embodiment, in the filename metadata810, the processor120or330may record the encrypted CI filename, the length of the encrypted CI filename, and the first hash value in a directory entry area of the original file, and in the filename metadata810, may separately record the bit information in a space for storing a file attribute of the original file or an extra attributes space.

According to an example embodiment, the processor120or330may generate a second CI filename in which a filename of the target file is expressed by the characters of the first type, may encrypt the second CI filename, may calculate a second hash value corresponding to the encrypted second CI filename, may perform a first comparison whether the first hash value coincides with the second hash value, and may search for the target file based on a result of the first comparison.

According to an example embodiment, when the result of the first comparison coincides, the processor120or330may perform a second comparison whether filename lengths and character strings of the encrypted CI filename recorded in the memory130,350, or670and the encrypted second CI filename coincide with each other, and may search for the target file based on a result of the second comparison.

According to an example embodiment, when the result of the second comparison coincides, the processor120or330may reconstruct the filename of the original file, and when the result of the second comparison does not coincide, may iteratively compare whether hash values corresponding to remaining filenames stored in the memory130,350, or670coincide with the second hash value.

According to an example embodiment, when the result of the second comparison coincides, based on the bit information, the processor120or330may reconstruct the filename of the original file by converting a character of the CI filename corresponding to an order of bits included in the bit information into an uppercase letter or a lowercase letter according to the bit information.

According to an example embodiment, when the result of the second comparison does not coincide, the processor120or330may, when a third hash value, which is one of the hash values, coincides with the second hash value, perform a third comparison whether filename lengths and character strings of an encrypted third CI filename corresponding to the third hash value and the encrypted second CI filename coincide with each other.

According to an example embodiment, a method of operating the electronic device101or301may include operation710of generating bit information corresponding to uppercase and lowercase letters included in a filename of an original file, operation720of generating a CI filename in which the filename of the original file is expressed by characters of a first type, operation730of encrypting the CI filename, operation740of calculating a first hash value corresponding to the encrypted CI filename, operation750of recording the filename metadata810including at least one of the encrypted CI filename, a length of the encrypted CI filename, the first hash value, and the bit information, in the memory130,350, or670, and operation760of searching for a target file to be found based on the filename metadata.

According to an example embodiment, the generating of the bit information may include generating the bit information by allocating a first bit value in correspondence to a position of an uppercase letter included in the filename of the original file and allocating a second bit value in correspondence to a position of a lowercase letter included in the filename of the original file.

According to an example embodiment, the recording of the filename metadata810in the memory130,350, or670may further include recording the filename metadata810in a different metadata area in the memory130,350, or670based on an attribute of the filename metadata, and storing the filename metadata810in a same metadata area in the memory130,350, or670.

According to an example embodiment, the operating method of the electronic device101or300may further include at least one of: in the filename metadata810, recording the encrypted CI filename, the length of the encrypted CI filename, and the first hash value in a directory entry area of the original file, and in the filename metadata810, separately recording the bit information in an i-node space of the original file or an extra attributes space.

According to an example embodiment, operation670of searching for the target file may include operation910of generating a second CI filename in which a filename of the target file is expressed by the characters of the first type, operation920of encrypting the second CI filename, operation930of calculating a second hash value corresponding to the encrypted second CI filename, operation940of performing a first comparison whether the first hash value coincides with the second hash value, and an operation of searching for the target file based on a result of the first comparison.

According to an example embodiment, when the result of the first comparison coincides, the searching for the target file may include operation950of performing a second comparison whether filename lengths and character strings of the encrypted CI filename recorded in the memory130,350, or670and the encrypted second CI filename coincide with each other, and operation960of searching for the target file based on a result of the second comparison.

According to an example embodiment, when a result of the second comparison coincides, the searching for the target file may include based on the bit information, reconstructing the filename of the original file by converting a character of the CI filename corresponding to an order of bits included in the bit information into an uppercase letter or a lowercase letter according to the bit information.

According to an example embodiment, when the result of the second comparison does not coincide, the searching for the target file may include iteratively comparing whether hash values corresponding to remaining filenames stored in the memory130,350, or670coincide with the second hash value.