KR20100018188A - Method for performing lock-setting on a file and terminal implementing the method - Google Patents

Method for performing lock-setting on a file and terminal implementing the method Download PDF

Info

Publication number
KR20100018188A
KR20100018188A KR1020080076848A KR20080076848A KR20100018188A KR 20100018188 A KR20100018188 A KR 20100018188A KR 1020080076848 A KR1020080076848 A KR 1020080076848A KR 20080076848 A KR20080076848 A KR 20080076848A KR 20100018188 A KR20100018188 A KR 20100018188A
Authority
KR
South Korea
Prior art keywords
file
fat
terminal
lock
attribute field
Prior art date
Application number
KR1020080076848A
Other languages
Korean (ko)
Inventor
용창육
Original Assignee
주식회사 케이티테크
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 케이티테크 filed Critical 주식회사 케이티테크
Priority to KR1020080076848A priority Critical patent/KR20100018188A/en
Publication of KR20100018188A publication Critical patent/KR20100018188A/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/604Tools and structures for managing or administering access control systems

Abstract

PURPOSE: A method for locking a file and a terminal performing the same are provided to display whether a file is locked using an attribute field of a directory entry of an FAT(File Allocation Table), thereby locking the file without changing contents of the file. CONSTITUTION: A memory(140) stores files and FAT directory entries about each file. If locking is selected when the files are stored, a controller(120) displays whether the files are locked on file attribute fields of FAT directory entries related to the files. The controller displays whether the files are locked using reserved bits.

Description

METHOD FOR PERFORMING LOCK-SETTING ON A FILE AND TERMINAL IMPLEMENTING THE METHOD}

The present invention relates to a method for locking a file and a terminal for performing the same.

Recently, embedded terminals such as mobile phones or MP3 players provide various additional functions in addition to communication functions or music playback functions which are unique to each other.

For example, the embedded terminal may store an image file or a text file and provide a viewer function to view the image file or the text file. As a result, someone other than the owner of these devices can view image files, video files, or text files stored on the device.

In order to prevent access to a file stored in the embedded terminal by another person, the embedded terminal provides a lock setting function to allow access to the file only when a predetermined password is input to the image file or the text file. Accordingly, in order to access a locked file in the embedded terminal, the user of the embedded terminal had to enter a password.

To this end, when a file is locked, a method of indicating whether the file is locked or not is displayed in a specific area of the file. For example, whether or not to lock the file is indicated by predefining a mark using the EXIF area of the JPEG file as the image file.

However, if you use this method to indicate whether the JPEG file is directly locked, the mobile device opens the file each time to check whether the file is locked, and searches the EXIF area to determine whether there is a specific bit pattern. The processing of the steps had to be carried out. For example, if you execute the photo album function, a list of photo files stored in the current album directory will be displayed, and there will be a need to distinguish and display files that are not locked.

For example, if you display a thumbnail list, the locked file must be handled differently depending on whether or not the lock is set, such as showing a lock icon instead of a thumbnail. As the number of files increases, the processing speed becomes an important problem. It is difficult to expect a fast process by directly locking the file using the EXIF area.

An object of the present invention for solving the above problems is to provide a file lock setting method that can facilitate the lock setting of the file in the terminal and a terminal for performing the same.

One embodiment of the present invention for achieving the above object is, a memory for storing a file (File Allocation Table) directory entry for each of the files and files, and when a lock setting for the file is selected when the file is stored, It provides a terminal including a control unit for displaying whether or not to lock the file in the file attribute field of the FAT directory entry associated with the file.

Here, the controller may indicate whether to lock the file by using a reserved bit of the file attribute field.

Here, the reserved bit may be the most significant bit of the file attribute field.

Here, when the lock setting for the file is selected, the controller may receive a password related to the file from the user.

Here, when access to the locked file occurs, the controller may request a user to input a password related to the file.

Here, the file may include an image file, a video file, a text file, and a sound file.

Another embodiment of the present invention for achieving the above object is, when storing a file in the terminal, determining whether the lock setting for the file is selected, and if the lock setting for the file is selected, And indicating whether to lock the file in a file attribute field of a file directory allocation (FAT) directory entry.

Here, whether to lock the file may be indicated by using a reserved bit of the file attribute field.

Here, the reserved bit may be the most significant bit of the file attribute field.

The file lock setting method may further include receiving a password related to the file from a user when a lock setting for the file is selected.

The file lock setting method may further include requesting a user to input a password related to the file when access to the locked file occurs.

Here, the file may include an image file, a video file, a text file, and a sound file.

According to the present invention as described above, it is possible to lock the file without changing the contents of the file because the terminal indicates whether to lock the file using the attribute field of the directory entry of the FAT. Accordingly, when the terminal accesses the locked file, the terminal can break the lock on the file without opening each file, and thus the time for reading the lock is shorter than in the conventional technology.

Further, according to the present invention, even if the terminal is connected to an external device such as a PC, since the contents of the existing FAT directory entry are not changed, the PC can access the files stored in the terminal without any obstacle. .

As the invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description. However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention. Like reference numerals are used for like elements in describing each drawing.

Terms such as first, second, A, and B may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component. The term and / or includes a combination of a plurality of related items or any item of a plurality of related items.

When a component is referred to as being "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may be present in between. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that no other component exists in the middle.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, the terms "comprise" or "have" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Embedded terminals, such as mobile phones and MP3 players, use FAT instead of their own format when considering file system compatibility. Here, FAT (File Allocation Table) refers to an area for recording location information and the like of a file stored in a memory in a file system.

For example, when an embedded terminal copies files from a PC, copies files after connecting to a removable storage device via USB, or uses an external storage medium such as an SD card, the format method is to maintain compatibility using FAT. It is common.

The FAT uses information called a directory entry to manage each file. The information includes a file name, a creation time, and status information. One-byte attribute field of these fields is used to record the state of the file as read only, system, hidden, etc.

The embedded terminal according to the present invention indicates whether a corresponding file is locked using a bit not used in the attribute field of the FAT directory entry.

Hereinafter, the configuration of the embedded terminal according to the present invention will be described with reference to FIG.

1 is a block diagram showing the configuration of an embedded terminal according to an embodiment of the present invention.

Referring to FIG. 1, the embedded terminal 100 includes a USB interface 160, a controller 120, a FAT 130, a memory 140, and a display 150 for communicating with an external device 200. .

The display unit 150 may be a liquid crystal display (LCD), an organic light emitting diode (OLED) panel, or the like.

The memory 140 stores an image file, a video file or a text file, a music file, and the like.

Specifically, the memory 140 is formatted by the FAT method, and the recording area of the memory 40 is divided into logical recording units called clusters composed of a predetermined number of sectors (for example, 64 sectors). Each cluster is given a cluster address, respectively. Management of writing and reading files to and from the information recording medium is performed in units of clusters.

The FAT 130 has a space corresponding to each of the clusters of the memory 140. Therefore, as the capacity of the memory 140 increases, the size of the FAT 130 also increases. Each space of the FAT is assigned a FAT address. In each space of the FAT, information indicating whether each cluster of the memory is used or used is recorded. The information indicating that the use is complete includes the address of the cluster in which the subsequent data is recorded when there is data following the data recorded in the cluster. If there is no subsequent data in the data recorded in the cluster (i.e., the file is terminated by the data recorded in the cluster), an end of file (EOF) is recorded.

In addition, a directory entry is recorded in association with each cluster of the memory 140 in order to manage the information and status of each file stored in the cluster of the memory 140.

2 shows the structure of a FAT directory entry.

Referring to FIG. 2, the directory entry 300 stores a file name field 301 for storing a file name, a file field Ext 302 for storing a file extension, and a file attribute. Field (Attr) 303, field for reserved use (NTRes: Reserved for use by Windows NT) 304, field for storing file creation time (C-Time) 305, file creation date A field for storing (C-Date) 306, a field for storing the last accessed date (Last Acc Date) 307, a field for storing a high word of the first cluster number of the entry ( First Clus Hi) 308, a field for storing the last write time (Write Time) 309, a field for storing the last write date (Write Date) 310, and a low word of the first cluster number of the entry ( Field for storing the low word (First Clus Low) 311 and field for storing the file size (File Size) 312. It is.

The present invention indicates whether to lock a file by using a field (hereinafter, referred to as a file attribute field) 303 for storing file attributes among the fields constituting the directory entry 300. The structure of the file attribute field 303 is shown in FIG.

3 is a diagram illustrating the structure of a general file attribute field.

Referring to FIG. 3, the file legend field 303 indicates whether writing to a file fails and indicates whether an indicator 410 with a mask value 0x01 and normal directory listings are shown in the file. Indicator 420 having a mask value of 0x02, indicating whether the file is an operating system file, indicator System having a mask value of 0x04, indicating whether a file exists in the root directory, and having a mask value of 0x08. Indicator 440 indicates whether the file is actually a container for another file, an indicator 450 having a mask value of 0x10, and a backup utility, and a mask value of 0x20. An indicator 460 is included.

In addition, the upper two bits 470 and 480 of one byte constituting the file comment field 303 are reserved. The present invention uses one of these spare bits 470, 480 as a flag bit for lock setting. The most significant bit 480 of these reserved bits has a mask value of 0x80, and the remaining reserved bits 470 have a mask value of 0x40.

As described above, the FAT indicates the file attribute by using each bit of each 1-byte attribute field, but the upper two bits 170 and 480 of the 1-byte are not used. According to the FAT32 Specificatioin document written by Microsoft, this area is initialized to zero at initial entry creation and should never be referenced afterwards. That is, existing FAT file systems do not assign values to this area, nor do they even read it at all.

That is, since the embedded terminal 100 does not change the contents of the existing FAT directory entry even when the embedded terminal 100 is connected to the external device 200, for example, the PC through the USB interface 160, the PC is configured to execute the memory 140 of the embedded terminal 100. ) Can be accessed without any obstacle. In FIG. 1, although the embedded terminal 100 is illustrated as being connected to the external device 200 through the USB interface 160, the embedded terminal 100 may be connected to the external device using Bluetooth and infrared communication, but the present invention is not limited thereto. .

Therefore, even if the embedded terminal is masked and used, the Windows operating system of the PC does not even inquire this area anyway when the terminal is connected to the PC as a removable disk. This experiment confirmed that there is no problem in marking this area in existing operating systems such as Windows and Linux.

Accordingly, when the control unit 120 stores the file in the memory 140, the control unit 120 locks the file to a predetermined reserved bit 470 or 480 of the attribute field 303 of the FAT directory entry 300 of the file. Whether or not In this case, the present invention preferably uses the most significant bit 480 of these reserved bits 470 and 480 as flag bits for lock setting. This is because, according to the FAT32 Specificatioin document, the reserved bit 470 is defined to be used for a specific purpose in the terminal.

Specifically, when the control unit 120 stores the file in the memory 140, if the predetermined file is locked by the user or by the embedded terminal itself, the control unit 120 presets the predetermined field of the attribute field 303 of the FAT directory entry 300. Bit 470 or 480 is set, for example.

Subsequently, when an access occurs to a file stored in the memory 140, the controller 120 refers to the predetermined reserved bit 470 or 480 of the attribute field 303 of the FAT directory entry 300 of the file. Determines whether the file is locked. If the predetermined reserved bit 470 or 480 of the attribute field 303 of the FAT directory entry 300 of the file is set, the controller 120 determines that the file is locked.

Accordingly, when an access occurs to a file stored in the memory 140, the controller 120 determines whether to lock the file by using the file attribute field 303 of the FAT directory entry 300. There is no need to open content directly. Therefore, the present invention is very fast in preparation for the technique of indicating whether or not the lock is directly set to the file, and in the implementation, the process of the corresponding field is slightly modified in the FAT file system. Compared to the method using the region, it can be easily implemented.

If the file is locked, the controller 120 may display a message on the display 150 instructing the user to input a password. In addition, the controller 120 may display a window for receiving a password from the user.

Meanwhile, according to another embodiment of the present invention, when a predetermined file is locked, the predetermined reserved bits 470 or 480 of the attribute field 303 of the FAT directory entry 300 may be configured to be reset, for example.

4 is a flowchart illustrating a method for locking a file according to an embodiment of the present invention.

Referring to FIG. 4, the embedded terminal determines whether a file is stored in step 510. The storage of the file may be selected by the user or may be automatically performed if a predetermined condition is met.

Subsequently, the embedded terminal determines whether to lock the file in operation 520. The lockout setting can be selected by the user to prevent the file from being accessed by others. In this case, the embedded terminal may receive a password required for the user to access the file, which is omitted in FIG. 4.

In addition, the embedded terminal may set a lock on the file if a predetermined condition is satisfied. In this case, the password associated with the file may be a password determined by default. For example, the user may determine in advance that the corresponding file is automatically locked when a picture is taken or recorded in the embedded terminal. In this case, the embedded terminal may lock the picture file or the sound file according to the recording.

If the lock setting is selected for the file, the embedded terminal indicates whether the lock is set in the file attribute field of the FAT directory entry in step 530. Specifically, the embedded terminal causes a specific bit of the file attribute field of the FAT directory entry to have a value indicating that the file lock is set. For example, the embedded terminal may set a predetermined reserved bit of the attribute field 303 of the FAT directory entry 300.

5 is a flowchart illustrating a method of controlling access to a locked file according to an embodiment of the present invention.

 Referring to FIG. 5, the embedded terminal determines whether access to a file stored in the memory 140 occurs in step 610. If an access occurs to a file stored in the memory 140, the embedded terminal proceeds to step 620 to determine whether to set a lock by referring to a file attribute field of a FAT directory entry related to the file.

Specifically, the embedded terminal refers to a predetermined reserved bit of the file attribute field of the FAT directory entry related to the accessed file to determine whether the file is locked. As a result, the embedded terminal checks in step 630 whether the predetermined reserved bit of the attribute field of the FAT directory entry of the file is locked, eg set.

If the predetermined reserved bit of the attribute field of the FAT directory entry of the file is locked, the embedded terminal receives the password from the user in step 640. In this case, the embedded terminal may display a message for instructing the user to input a password and a window for receiving a password from the user.

The embedded terminal then determines whether the password received from the user in step 650 is a legitimate password. This password may be input from the user when the file is locked, or may be input in advance by the user by default.

If the password entered from the user is a legitimate password, then access to the file is allowed in step 660 if the password entered from the user is a legitimate password. However, if the password entered from the user is not a valid password, the embedded terminal prohibits access to the file at step 670. In this case, the embedded terminal may wait to input the password a predetermined number of times.

Files locked in the above detailed description include image files, video files, text files, and sound files.

Although described above with reference to a preferred embodiment of the present invention, those skilled in the art will be variously modified and changed within the scope of the invention without departing from the spirit and scope of the invention described in the claims below I can understand that you can.

1 is a block diagram showing the configuration of an embedded terminal according to an embodiment of the present invention.

2 shows the structure of a FAT directory entry.

3 is a diagram illustrating the structure of a general file attribute field.

4 is a flowchart illustrating a method for locking a file according to an embodiment of the present invention.

5 is a flowchart illustrating a method of controlling access to a locked file according to an embodiment of the present invention.

<Explanation of symbols for the main parts of the drawings>

100: embedded terminal

120: control unit

130: FAT

140: memory

150: display unit

Claims (12)

Memory for storing files and a File Allocation Table (FAT) directory entry for each of the files, And a control unit for displaying whether or not to lock the file in a file attribute field of a FAT directory entry associated with the file when the file is locked. The terminal of claim 1, wherein the controller is configured to indicate whether to lock the file by using a reserved bit of the file attribute field. The terminal of claim 2, wherein the reserved bits are the most significant bits of the file attribute field. The terminal of claim 1, wherein the control unit receives a password related to the file from a user when a lock setting for the file is selected. The terminal of claim 1, wherein the control unit requests a user to input a password related to the file when access to the locked file occurs. The terminal of claim 1, wherein the file comprises an image file, a video file, a text file, and a sound file. In the method for locking a file in the terminal, When saving a file, determining whether a lock setting for the file is selected; And if the lock setting for the file is selected, indicating whether to lock the file in a file attribute field of a file allocation table (FAT) directory entry associated with the file. The method of claim 7, wherein the locking of the file is indicated by using a reserved bit of the file attribute field. 10. The method of claim 8, wherein the reserved bit is the most significant bit of the file attribute field. 8. The method of claim 7, further comprising receiving a password in association with the file from a user when the lock setting for the file is selected. The method of claim 7, further comprising requesting a user to input a password associated with the file when access to the locked file occurs. The method of claim 7, wherein the file comprises an image file, a video file, a text file, and a sound file.
KR1020080076848A 2008-08-06 2008-08-06 Method for performing lock-setting on a file and terminal implementing the method KR20100018188A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020080076848A KR20100018188A (en) 2008-08-06 2008-08-06 Method for performing lock-setting on a file and terminal implementing the method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020080076848A KR20100018188A (en) 2008-08-06 2008-08-06 Method for performing lock-setting on a file and terminal implementing the method

Publications (1)

Publication Number Publication Date
KR20100018188A true KR20100018188A (en) 2010-02-17

Family

ID=42088972

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020080076848A KR20100018188A (en) 2008-08-06 2008-08-06 Method for performing lock-setting on a file and terminal implementing the method

Country Status (1)

Country Link
KR (1) KR20100018188A (en)

Similar Documents

Publication Publication Date Title
US5530235A (en) Interactive contents revealing storage device
US8239395B2 (en) Storage device presenting to hosts only files compatible with a defined host capability
KR100738172B1 (en) Electronic device for managing removable storage medium, method and storage medium therefor
US7861311B2 (en) Apparatus and method of managing hidden area
EP1942636B1 (en) System and method for a portable memory device to access and acquire additional memory from a remote location
US20030225960A1 (en) Method for partitioning memory mass storage device
US20120265792A1 (en) Data storage access device
US8819315B2 (en) Storage device with display unit and method of displaying information
US20080005531A1 (en) Data Storage Device
JP5558093B2 (en) Semiconductor device and memory system
KR20100018188A (en) Method for performing lock-setting on a file and terminal implementing the method
TWI407327B (en) Method and system for processing data, and storage device controller
JP2005157768A (en) Method for storing electronic file, implementation device, and processing program
JP2006106941A (en) File synchronization system
JP2005109869A (en) Method for managing encryption key
JP2007148566A (en) Data writing device and data reading device

Legal Events

Date Code Title Description
WITN Withdrawal due to no request for examination