CN116431578A - 文件清理方法、装置、电子设备及存储介质 - Google Patents

文件清理方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN116431578A
CN116431578A CN202310337842.5A CN202310337842A CN116431578A CN 116431578 A CN116431578 A CN 116431578A CN 202310337842 A CN202310337842 A CN 202310337842A CN 116431578 A CN116431578 A CN 116431578A
Authority
CN
China
Prior art keywords
file
target file
time
access time
last access
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202310337842.5A
Other languages
English (en)
Inventor
席玉祥
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Baidu Netcom Science and Technology Co Ltd
Original Assignee
Beijing Baidu Netcom Science and Technology Co Ltd
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 Beijing Baidu Netcom Science and Technology Co Ltd filed Critical Beijing Baidu Netcom Science and Technology Co Ltd
Priority to CN202310337842.5A priority Critical patent/CN116431578A/zh
Publication of CN116431578A publication Critical patent/CN116431578A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/13File access structures, e.g. distributed indices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/1734Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开涉及数据存储技术领域,尤其涉及文件清理方法、装置、电子设备及存储介质。具体实现方案为:调用监控通知机制对目标文件进行监控;响应于目标文件发生监控事件,对目标文件的最后访问时间进行更新;响应于文件清理机制被触发,获取每个目标文件的最后访问时间;根据最后访问时间,确定目标文件中的过期文件;对过期文件进行清理。通过监控目标文件,在监控到目标文件发生监控时间时,对目标文件的访问时间进行更新,从而提升对磁盘文件清理的效果,减少过期文件对磁盘空间的占用。

Description

文件清理方法、装置、电子设备及存储介质
技术领域
本公开涉及数据存储技术领域,尤其涉及文件清理方法、装置、电子设备及存储介质。
背景技术
在移动APP(Application,应用程序)迅速发展的今天,各类APP产生的文件占用了大量磁盘空间,对于手机设备空间比较有限的用户来说,APP磁盘占用空间对用户的忠诚度起着特别大的影响。
首先在分析磁盘占用问题过程中,会发现存在大量的长时间不访问的文件,目前,可以根据文件的最后访问时间来判断文件是否长时间未被访问,若文件的最后访问时间距离当前时间达到设定的过期阈值,即为过期文件,例如,文件的最后访问时间是31天前,过期阈值为30天,则该文件为过期文件。需要通过清理机制对这些过期文件进行清理,减少过期文件对磁盘空间的占用。
但是由于Android***为了提升IO(Input/Output,输入/输出)性能,在挂载文件***时会指定“noatime”参数,指定该参数后,atime(access time,访问时间)就是文件创建时间,意味着文件在被访问时atime不会随之更新,即无法获取到文件真实的最后访问时间。这样就可能造成***误清理文件,例如,用户昨天刚访问过的文件,因atime大于过期阈值而被***当作过期文件清理,从而无法对磁盘文件进行合理的清理,可能造成用户体验不佳。
发明内容
针对现有技术中磁盘文件不能得到合理清理的技术问题,本公开提供了一种文件清理方法、装置、电子设备、存储介质、计算机程序产品。
根据本公开的第一方面,提供了一种文件清理方法,包括:
调用监控通知机制对目标文件进行监控;
响应于所述目标文件发生监控事件,对所述目标文件的所述最后访问时间进行更新;
响应于文件清理机制被触发,获取每个所述目标文件的最后访问时间;
根据所述最后访问时间,确定所述目标文件中的过期文件;
对所述过期文件进行清理。
根据本公开的第二方面,提供了一种文件清理装置,包括:
文件监控模块,被配置为调用监控通知机制对目标文件进行监控;
文件时间更新模块,被配置为响应于所述目标文件发生监控事件,对所述目标文件的所述最后访问时间进行更新;
获取模块,被配置为响应于文件清理机制被触发,获取每个所述目标文件的最后访问时间;
确定模块,被配置为根据所述最后访问时间,确定所述目标文件中的过期文件;
文件清理模块,被配置为对所述过期文件进行清理。
根据本公开的第三方面,提供了一种电子设备,包括:
至少一个处理器;以及
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行上述技术方案中任一项所述的方法。
根据本公开的第四方面,提供了一种存储有计算机指令的非瞬时计算机可读存储介质,其中,所述计算机指令用于使所述计算机执行上述技术方案中任一项所述的方法。
根据本公开的第五方面,提供了一种计算机程序产品,包括计算机程序,所述计算机程序在被处理器执行时实现上述技术方案中任一项所述的方法。
本公开提供了文件清理方法、装置、电子设备、存储介质、计算机程序产品,提升对磁盘文件清理的效果,减少过期文件对磁盘空间的占用。
应当理解,本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征,也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
附图用于更好地理解本方案,不构成对本公开的限定。其中:
图1是本公开实施例中的文件清理方法的步骤示意图;
图2是本公开实施例中的判断过期文件的流程示意图;
图3是本公开实施例中的文件清理机制的触发流程图;
图4是本公开实施例中的判断文件最后访问时间是否有效的流程图;
图5是本公开实施例中的文件清理装置的原理框图;
图6是本公开实施例中的另一种文件清理装置的原理框图;
图7是本公开实施例中的磁盘过期文件检查***的整体框架图;
图8是用来实现本公开实施例的文件清理方法的电子设备的框图。
具体实施方式
以下结合附图对本公开的示范性实施例做出说明,其中包括本公开实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本公开的范围和精神。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。
现有的文件监控方案包括以下几种:
方案一,通过循环读取文件目录,当文件被读取打开时,首先会在该目录创建相应的文件句柄,通过循环读取该目录的文件句柄信息,获取到被打开文件路径,进而对文件的访问时间进行更新。但是当文件较小时,读取文件的时间会比较短,若在读取完毕后及时关闭数据流,通过轮询的方式读取文件句柄信息,可能会存在无法及时获取到句柄的现象,从而导致文件监控丢失问题,无法覆盖全部的读写场景。
方案二:通过hook方案,当hook当文件发生IO(输入/输出)操作时,获取文件的路径,更新文件时间。但hook方案存在性能问题,hook机制会发生反射过程,兼容性差,JavaHook需要和每个Android版本去兼容,特别是Android P增加对非公开API(ApplicationProgramming Interface,应用程序编程接口)限制。
方案三:通过inotify+epoll机制,通过inotify机制对指定文件句柄添加监控,并结合epoll机制(epoll是Linux内核为处理大批量文件描述符而作了改进的poll,它能显著提高程序在大量并发连接中只有少量活跃的情况下的***CPU利用率)在文件被读取是触发epoll回调,进而更新文件时间。通过linux epoll机制同时监控多个文件fd(Filedescriptor,文件描述符),文件监控可只存在一个inotify fd,并且可以通过linux ioread方法直接读取inotify event管道中的文件信息,使用epoll添加监控会带来额外的性能消耗。
方案四:通过Android FileObserver(安卓文件监控器)API监控指定目录内文件操作,当文件有读写等操作时触发回调,进而更新文件时间。Android***APIFileObserver类添加监控目录时,若多个实例监控同一个目录,会存在多个实例相互覆盖的问题,因为FileObserver实现是通过HashMap(哈希映射)来存在监控监控目录和监控实例信息,从而当对同一个目录创建多个实例时,HashMap只会存储一个实例,当FileObserver触发事件回调时,只会对一个监控实例触发回调,会导致其它实例监控失效。
基于上述技术问题,若要对磁盘过期文件进行科学有效的清理,需解决文件访问时间无法时更新等问题。本公开提供了一种文件清理方法,如图1所示,包括:
步骤S101,调用监控通知机制对目标文件进行监控。
示例性地,监控通知机制可以采用inotify机制,其监控的目标文件可以是单个文件也可以是包括多个文件的文件目录,通过inotify机制进行监控,监控文件是否发生监控事件,监控事件包括但不限于OPEN(打开)事件、ACCESS(访问)事件、MODIFY(修改)事件等。
步骤S102,响应于目标文件发生监控事件,对目标文件的最后访问时间进行更新。
在被监控文件被读取或更新时,inotify机制监控到相应的事件,监控实例回调相应的事件通知,为保证监控的覆盖度,监控方案需要针对不同的文件读取方式在不同的时机对文件的时间进行更新。通过对文件的访问时间进行及时更新,确保最后访问时间的真实性,避免文件清理机制基于错误的最后访问时间判断文件是否过期,从而造成文件的误清理。
步骤S103,响应于文件清理机制被触发,获取每个目标文件的最后访问时间。
示例性地,本公开的文件清理流程在文件清理机制被触发后开始执行,例如,***的磁盘空间不足时,或者在磁盘空间占用率达到一定阈值,或者***定期清理等情况。
步骤S104,根据最后访问时间,确定目标文件中的过期文件。
示例性地,例如最后访问时间是2023年3月1日,当前时间是2023年3月21日,***预设的过期阈值是15天,即文件超过15天没有访问,那么判断该文件为过期文件。
步骤S105,对过期文件进行清理。
示例性地,可以将过期文件回调给业务方,业务方根据quota目录自行清理。其中,quota是一个Linux命令,显示磁盘使用情况和限额。
作为可选的实施方式,步骤S101调用监控通知机制对目标文件进行监控包括:
在Java层添加单个文件或创建包括多个文件的目标文件目录作为目标文件;
利用Java层的Java本地接口调用监控通知机制,通过监控通知机制对所有目标文件进行监控;
响应于目标文件发生所述监控事件,通过Java本地接口回调,将监控事件对应的信息写入目标文件对应的文件描述符。
通过Java层接口添加文件、文件目录监控,jni(Java Native Interface,Java本地接口)调用inotify实现,并通过jni反向回调方式,在inotify监控到文件操作事件时,触发Java层回调,将监控事件通知监控实例,实现监控闭环。本实施例中通过优化存储数据结构解决了Android FileObserver存在的同一目录监控多监控实例覆盖的问题。
作为可选的实施方式,监控事件包括打开事件或访问事件;响应于目标文件发生监控事件,对目标文件的最后访问时间进行更新包括:
响应于目标文件发生OPEN事件或ACCESS事件,对目标文件的最后访问时间进行更新。
具体地,当在Android***中,文件读取方式一般包括常规IO数据流和mmap两种读取方式,针对不同的读取方式,对目标文件的最后访问时间更新的时机也不同,具体包括:
当使用数据流(IO)方式读取目标文件时,响应于目标文件发生OPEN事件或ACCESS事件,对目标文件的最后访问时间进行更新。数据流方式读取目标文件时,首先通过open方法打开文件并创建文件句柄,然后读取文件,经验证,在添加inotify监听后,会触发OPEN事件、ACCESS两个事件回调。
当使用数据流方式更新目标文件时,响应于目标文件发生OPEN事件或MODIFY事件,对目标文件的最后访问时间进行更新。数据流方式更新文件时,首先通过open方法打开文件并创建文件句柄,然后写入文件,经验证,在添加inotify监听后,会触发OPEN事件、MODIFY两个事件回调。
当使用内存映射文件(mmap)方式读取目标文件时,响应于目标文件发生OPEN事件,对目标文件的最后访问时间进行更新。通过mmap方式读取文件,***会创建新的虚拟内存区域并和文件磁盘地址建立映射,不发生任何的拷贝操作,在进行文件读取时,会通过open方法打开文件,进而进行文件读取,经验证,在添加inotify监听后,仅会触发OPEN事件回调。
通过上述分析,通过监听OPEN事件、ACCESS事件即可以覆盖Android***所有的文件读写操作,避免文件监控丢失问题,从而实现及时地对文件访问时间进行更新,确保后续对文件的有效清理。本实施例中可以基于inotify机制实现对文件的监控,并在合适的时机对文件的最后访问时间进行更新,保证了文件访问时间的准确性,在磁盘过期文件检查时根据文件的最后访问时间可判断哪些文件是否过期,从而对过期文件进行清理,减少APP磁盘占用空间。
作为可选的实施方式,通过调用liunx utimes方法来更新文件的最后访问时间。在更新文件时间时,Android***会首先通过open方法打开文件,创建文件句柄,然后判断如果支持futimes更新会调用linux futimes方法进行更新时间,futimes最终调用了linuxutimes方法。如果采用这种方式更新文件时间,当调用该方法时文件监听会触发OPEN事件回调,然而如前所述,文件时间更新时机也是在OPEN事件回调时进行更新,从而会发生递归调用,造成死循环问题。由于futimes最终会调用utimes方法(futimes和utimes都是改变时间戳的应用程序接口),因此可以直接采用jni方式,通过在jni层直接调用liunx utimes方法来更新文件时间,从而避免了递归调用的问题。通过以上机制,可实现对文件的监控和文件时间同步更新,保证了文件的访问时间的准确性,为磁盘清理过期文件起到关键性作用。
作为可选的实施方式,如图2所示,步骤S104根据最后访问时间,确定目标文件中的过期文件包括:
步骤S201,遍历目标文件;
步骤S202,检查目标文件的最后访问时间是否有效;
步骤S203,响应于最后访问时间有效,根据最后访问时间,确定对目标文件中的过期文件。
在文件清理机制被触发时,遍历所有的目标文件,检查每个文件、文件目录的最后访问时间是否有效,在判断文件的最后访问时间有效后,才会基于最后访问时间决定是否对文件进行清理;如果文件的最后访问时间无效,则判断该文件没有过期,避免对文件造成误清理。本实施例中首先判断文件的最后访问时间是否有效,再判断文件是否过期,可以提升文件清理的准确率,避免造成用户重要文件的误清理,导致用户体验不佳。
示例性地,如图4所示,检查目标文件的最后访问时间是否有效包括:
步骤S401,检查监控通知机制是否开启;
步骤S402,响应于监控通知机制已开启,判断当前时间与监控开始时间之间的第一差值是否大于预设过期阈值;
若第一差值大于预设过期阈值,确定最后访问时间有效;
若第一差值不大于预设过期阈值,确定最后访问时间无效。
本实施例通过上述技术方案准确判断访问时间的有效性。示例性地,如图4所示,判断文件的最后访问时间atime是否有效,步骤S401,首先检查是否开启了文件的监控通知机制,若没有开启,则直接判断atime无效。进一步地,在确定开启监控通知机制之后,步骤S401,再判断atime是否处于监控通知机制的生效区间内,若当前时间与监控开始时间之间的差值大于预设过期阈值,则判断atime有效,反之则无效。例如监控通知机制仅生效15天,而获取的文件atime为30天,则判断该atime无效。
监控通知机制上线后,开始监控文件操作并更新文件时间,若判断文件是否过期,需判断的时间区间处于监控通知机制生效区间内,预设过期阈值根据实际应用场景而定,可以设置为30天,比如要判断30天不访问的过期文件,需要监控通知机制上线30天后进行检查,atime即为真实有效时间,否则atime时间不准确,无法根据atime来判断文件是否过期。
作为可选的实施方式,如图2所示,步骤S203,根据最后访问时间,确定目标文件中的过期文件包括:
步骤S2031,获取目标文件的最后修改时间,将最后访问时间与最后修改时间进行对比;
步骤S2032,响应于最后访问时间晚于最后修改时间,计算当前时间与最后访问时间之间的第二差值,确定第二差值大于预设过期阈值的目标文件为过期文件;
步骤S2033,响应于最后访问时间早于最后修改时间,计算当前时间与最后修改时间之间的第三差值,确定第三差值大于预设过期阈值的目标文件为过期文件。
具体地,最后访问时间表示为atime,最后修改时间表示为mtime,当前时间表示为current time,预设过期阈值表示为expired time。本实施例中,atime>mtime时,根据atime来判断文件是否过期,相反,则用mtime来判断文件是否过期,简而言之,使用atime和mtime中更接近当前时间的文件时间来判断文件是否过期,从而更准确判断文件是否过期。其中,预设过期阈值可以根据实际应用场景来设定,例如设置为30天,当文件的最后访问时间大于30天,将该文件作为过期文件清理。通常文件的最后访问时间和最后修改时间会不一致,例如,用户在2023年3月1日,19:42访问了文件,在19:48对文件进行了修改,最后访问时间是19:42分,最后修改时间是19:48。本实施例中在判断文件是否过期时,以最后访问时间和最后修改时间中较新的时间为准,进一步提升文件清理的准确率,避免造成误清理,任意一个时间没有大于30天,文件都不会被判断为过期文件。
作为可选的实施方式,文件清理机制的触发流程包括:
响应于应用程序冷启动达到第一预设时间或应用程序返回前台,并在应用程序满足文件清理条件时,触发文件清理机制;
其中,应用程序满足所述文件清理条件包括:当前时间与上一次文件清理时间之间的第四差值达到预设清理阈值,并且满足所述应用程序覆盖升级或用户磁盘状态发生变动。
示例性地,如图3所示,业务方注册清理通知,是否启动自动清理机制的检测时机是,当APP每次冷启2min后和每次返回前台时,触发自动清理机制,通知业务清理的条件是,首先判断是否距上次清理时间大于30min,且满足覆盖升级、用户磁盘状态发生变任一条件后通知业务方进行清理,此时开始检查过期文件,并将过期文件回调给业务方,业务方根据quota目录自行清理。其中,quota是一个Linux命令,显示磁盘使用情况和限额。
本公开还提供了一种文件清理装置500,如图5所示,包括:
文件监控模块501,被配置为调用监控通知机制对目标文件进行监控。
示例性地,监控通知机制可以采用inotify机制,其监控的目标文件可以是单个文件也可以是包括多个文件的文件目录,通过inotify机制进行监控,监控文件是否发生监控事件,监控事件包括但不限于OPEN事件、ACCESS事件、MODIFY事件等。
文件时间更新模块502,被配置为响应于目标文件发生监控事件,对目标文件的最后访问时间进行更新。
在被监控文件被读取或更新时,inotify机制监控到相应的事件,监控实例回调相应的事件通知,为保证监控的覆盖度,监控方案需要针对不同的文件读取方式在不同的时机对文件的时间进行更新。通过对文件的访问时间进行及时更新,确保最后访问时间的真实性,避免文件清理机制基于错误的最后访问时间判断文件是否过期,从而造成文件的误清理。
获取模块503,被配置为响应于文件清理机制被触发,获取每个目标文件的最后访问时间。
示例性地,本公开的文件清理流程在文件清理机制被触发后开始执行,例如,***的磁盘空间不足时,或者在磁盘空间占用率达到一定阈值,或者***定期清理等情况。
确定模块504,被配置为根据最后访问时间,确定目标文件中的过期文件。
示例性地,例如最后访问时间是2023年3月1日,当前时间是2023年3月21日,***预设的过期阈值是15天,即文件超过15天没有访问,那么判断该文件为过期文件。
文件清理模块505,被配置为对过期文件进行清理。
示例性地,可以将过期文件回调给业务方,业务方根据quota目录自行清理。其中,quota是一个Linux命令,显示磁盘使用情况和限额。
作为可选的实施方式,文件监控模块501调用监控通知机制对目标文件进行监控包括:
在Java层添加单个文件或创建包括多个文件的目标文件目录作为目标文件;
利用Java层的Java本地接口调用监控通知机制,通过监控通知机制对所有目标文件进行监控;
响应于目标文件发生所述监控事件,通过Java本地接口回调,将监控事件对应的信息写入目标文件对应的文件描述符。
通过Java层接口添加文件、文件目录监控,jni调用inotify实现,并通过jni反向回调方式,在inotify监控到文件操作事件时,触发Java层回调,将监控事件通知监控实例,实现监控闭环。本实施例中通过优化存储数据结构解决了Android FileObserver存在的同一目录监控多监控实例覆盖的问题。
作为可选的实施方式,监控事件包括打开事件或访问事件;文件时间更新模块502响应于目标文件发生监控事件,对目标文件的最后访问时间进行更新包括:
响应于目标文件发生OPEN事件或ACCESS事件,对目标文件的最后访问时间进行更新。
具体地,当在Android***中,文件读取方式一般包括常规IO数据流和mmap两种读取方式,针对不同的读取方式,对目标文件的最后访问时间更新的时机也不同,具体包括:
当使用数据流方式读取目标文件时,响应于目标文件发生OPEN事件或ACCESS事件,对目标文件的最后访问时间进行更新。数据流方式读取目标文件时,首先通过open方法打开文件并创建文件句柄,然后读取文件,经验证,在添加inotify监听后,会触发OPEN事件、ACCESS两个事件回调。
当使用数据流方式更新目标文件时,响应于目标文件发生OPEN事件或MODIFY事件,对目标文件的最后访问时间进行更新。数据流方式更新文件时,首先通过open方法打开文件并创建文件句柄,然后写入文件,经验证,在添加inotify监听后,会触发OPEN事件、MODIFY两个事件回调。
当使用mmap方式读取目标文件时,响应于目标文件发生OPEN事件,对目标文件的最后访问时间进行更新。通过mmap方式读取文件,***会创建新的虚拟内存区域并和文件磁盘地址建立映射,不发生任何的拷贝操作,在进行文件读取时,会通过open方法打开文件,进而进行文件读取,经验证,在添加inotify监听后,仅会触发OPEN事件回调。
通过上述分析,通过监听OPEN事件、ACCESS事件即可以覆盖Android***所有的文件读写操作,避免文件监控丢失问题,从而实现及时地对文件访问时间进行更新,确保后续对文件的有效清理。本实施例中可以基于inotify机制实现对文件的监控,并在合适的时机对文件的最后访问时间进行更新,保证了文件访问时间的准确性,在磁盘过期文件检查时根据文件的最后访问时间可判断哪些文件是否过期,从而对过期文件进行清理,减少APP磁盘占用空间。
作为可选的实施方式,文件时间更新模块502通过调用liunx utimes方法来更新文件的最后访问时间。在更新文件时间时,Android***会首先通过open方法打开文件,创建文件句柄,然后判断如果支持futimes更新会调用linux futimes方法进行更新时间,futimes最终调用了linux utimes方法。如果采用这种方式更新文件时间,当调用该方法时文件监听会触发OPEN事件回调,然而如前所述,文件时间更新时机也是在OPEN事件回调时进行更新,从而会发生递归调用,造成死循环问题。由于futimes最终会调用utimes方法(futimes和utimes都是改变时间戳的应用程序接口),因此可以直接采用jni方式,通过在jni层直接调用liunx utimes方法来更新文件时间,从而避免了递归调用的问题。通过以上机制,可实现对文件的监控和文件时间同步更新,保证了文件的访问时间的准确性,为磁盘清理过期文件起到关键性作用。
作为可选的实施方式,如图2所示,确定模块504根据最后访问时间,确定目标文件中的过期文件包括:
遍历单元,被配置为遍历目标文件;
检查单元,被配置为检查目标文件的最后访问时间是否有效;
确定单元,被配置为响应于最后访问时间有效,根据最后访问时间,确定对目标文件中的过期文件。
在文件清理机制被触发时,遍历所有的目标文件,检查每个文件、文件目录的最后访问时间是否有效,在判断文件的最后访问时间有效后,才会基于最后访问时间决定是否对文件进行清理;如果文件的最后访问时间无效,则判断该文件没有过期,避免对文件造成误清理。本实施例中首先判断文件的最后访问时间是否有效,再判断文件是否过期,可以提升文件清理的准确率,避免造成用户重要文件的误清理,导致用户体验不佳。
示例性地,如图4所示,确定模块504检查目标文件的最后访问时间是否有效包括:
步骤S401,检查监控通知机制是否开启;
步骤S402,响应于监控通知机制已开启,判断当前时间与监控开始时间之间的第一差值是否大于预设过期阈值;
若第一差值大于预设过期阈值,确定最后访问时间有效;
若第一差值不大于预设过期阈值,确定最后访问时间无效。
示例性地,如图4所示,判断文件的最后访问时间atime是否有效,步骤S401,首先检查是否开启了文件的监控通知机制,若没有开启,则直接判断atime无效。进一步地,在确定开启监控通知机制之后,步骤S401,再判断atime是否处于监控通知机制的生效区间内,若当前时间与监控开始时间之间的差值大于预设过期阈值,则判断atime有效,反之则无效。例如监控通知机制仅生效15天,而获取的文件atime为30天,则判断该atime无效。
监控通知机制上线后,开始监控文件操作并更新文件时间,若判断文件是否过期,需判断的时间区间处于监控通知机制生效区间内,预设过期阈值根据实际应用场景而定,可以设置为30天,比如要判断30天不访问的过期文件,需要监控通知机制上线30天后进行检查,atime即为真实有效时间,否则atime时间不准确,无法根据atime来判断文件是否过期。
作为可选的实施方式,确定模块504根据最后访问时间,确定目标文件中的过期文件包括:
如图2所示,步骤S2031,获取目标文件的最后修改时间,将最后访问时间与最后修改时间进行对比;
步骤S2032,响应于最后访问时间晚于最后修改时间,计算当前时间与最后访问时间之间的第二差值,确定第二差值大于预设过期阈值的目标文件为过期文件;
步骤S2033,响应于最后访问时间早于最后修改时间,计算当前时间与最后修改时间之间的第三差值,确定第三差值大于预设过期阈值的目标文件为过期文件。
具体地,最后访问时间表示为atime,最后修改时间表示为mtime,当前时间表示为current time,预设过期阈值表示为expired time。本实施例中,atime>mtime时,根据atime来判断文件是否过期,相反,则用mtime来判断文件是否过期,简而言之,使用atime和mtime中更接近当前时间的文件时间来判断文件是否过期,从而更准确判断文件是否过期。其中,预设过期阈值可以根据实际应用场景来设定,例如设置为30天,当文件的最后访问时间大于30天,将该文件作为过期文件清理。通常文件的最后访问时间和最后修改时间会不一致,例如,用户在2023年3月1日,19:42访问了文件,在19:48对文件进行了修改,最后访问时间是19:42分,最后修改时间是19:48。本实施例中在判断文件是否过期时,以最后访问时间和最后修改时间中较新的时间为准,任意一个时间没有大于30天,文件都不会被判断为过期文件。
作为可选的实施方式,如图6所示,文件清理装置还包括:
触发模块506,被配置为响应于应用程序冷启动达到第一预设时间或应用程序返回前台,并在应用程序满足文件清理条件时,触发文件清理机制;其中,应用程序满足文件清理条件包括:当前时间与上一次文件清理时间之间的第四差值达到预设清理阈值,并且满足应用程序覆盖升级或用户磁盘状态发生变动。
示例性地,如图3所示,业务方注册清理通知,是否启动自动清理机制的检测时机是,当APP每次冷启2min后和每次返回前台时,触发自动清理机制,通知业务清理的条件是,首先判断是否距上次清理时间大于30min,且满足覆盖升级、用户磁盘状态发生变任一条件后通知业务方进行清理,此时开始检查过期文件,并将过期文件回调给业务方,业务方根据quota目录自行清理。其中,quota是一个Linux命令,显示磁盘使用情况和限额。
本公开还提供了一种磁盘过期文件检查整体框架,如图7所示,包括:
云控配置模块701,负责管理和存储磁盘目录、磁盘等级、quota值、监控目录及策略的云端配置数据。
文件监控模块702,基于inotify机制实现文件目录监控及atime更新,通过注册监控目录,监听到文件读取事件时更新文件访问时间。
磁盘管控模块703,磁盘检查入口,策略触发检查当前磁盘等级、过期文件,并提供自动清理监控、文件目录监控能力,触发自动清理时回调自动清理和过期文件通知。
本公开的技术方案中,所涉及的用户个人信息的获取,存储和应用等,均符合相关法律法规的规定,且不违背公序良俗。
根据本公开的实施例,本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
图8示出了可以用来实施本公开的实施例的示例电子设备800的示意性框图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本公开的实现。
如图8所示,设备800包括计算单元801,其可以根据存储在只读存储器(ROM)802中的计算机程序或者从存储单元808加载到随机访问存储器(RAM)803中的计算机程序,来执行各种适当的动作和处理。在RAM 803中,还可存储设备800操作所需的各种程序和数据。计算单元801、ROM 802以及RAM803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。
设备800中的多个部件连接至I/O接口805,包括:输入单元806,例如键盘、鼠标等;输出单元807,例如各种类型的显示器、扬声器等;存储单元808,例如磁盘、光盘等;以及通信单元809,例如网卡、调制解调器、无线通信收发机等。通信单元809允许设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
计算单元801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元801的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习目标函数算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元801执行上文所描述的各个方法和处理,例如文件清理方法。例如,在一些实施例中,文件清理方法可被实现为计算机软件程序,其被有形地包含于机器可读介质,例如存储单元808。在一些实施例中,计算机程序的部分或者全部可以经由ROM 802和/或通信单元809而被载入和/或安装到设备800上。当计算机程序加载到RAM803并由计算单元801执行时,可以执行上文描述的文件清理方法的一个或多个步骤。备选地,在其他实施例中,计算单元801可以通过其他任何适当的方式(例如,借助于固件)而被配置为执行文件清理方法。
本文中以上描述的***和技术的各种实施方式可以在数字电子电路***、集成电路***、现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上***的***(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程***上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储***、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储***、该至少一个输入装置、和该至少一个输出装置。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行***、装置或设备使用或与指令执行***、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体***、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
为了提供与用户的交互,可以在计算机上实施此处描述的***和技术,该计算机具有:用于向用户显示信息的显示装置(例如,CRT(阴极射线管)或者LCD(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的***和技术实施在包括后台部件的计算***(例如,作为数据服务器)、或者包括中间件部件的计算***(例如,应用服务器)、或者包括前端部件的计算***(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的***和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算***中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将***的部件相互连接。通信网络的示例包括:局域网(LAN)、广域网(WAN)和互联网。
计算机***可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器,也可以为分布式***的服务器,或者是结合了区块链的服务器。
应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本公开公开的技术方案所期望的结果,本文在此不进行限制。
上述具体实施方式,并不构成对本公开保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等,均应包含在本公开保护范围之内。

Claims (17)

1.一种文件清理方法,包括:
调用监控通知机制对目标文件进行监控;
响应于所述目标文件发生监控事件,对所述目标文件的所述最后访问时间进行更新;
响应于文件清理机制被触发,获取每个所述目标文件的最后访问时间;
根据所述最后访问时间,确定所述目标文件中的过期文件;
对所述过期文件进行清理。
2.根据权利要求1所述的方法,所述调用监控通知机制对目标文件进行监控包括:
在Java层添加单个文件或创建包括多个文件的目标文件目录作为所述目标文件;
利用所述Java层的Java本地接口调用所述监控通知机制,通过所述监控通知机制对所有所述目标文件进行监控;
响应于所述目标文件发生所述监控事件,通过所述Java本地接口回调,将所述监控事件对应的信息写入所述目标文件对应的文件描述符。
3.根据权利要求1所述的方法,其中,所述监控事件包括打开事件或访问事件;所述响应于所述目标文件发生监控事件,对所述目标文件的所述最后访问时间进行更新包括:
响应于所述目标文件发生所述打开事件或所述访问事件,对所述目标文件的所述最后访问时间进行更新。
4.根据权利要求1-3中任意一项所述的方法,所述根据所述最后访问时间,确定所述目标文件中的过期文件包括:
遍历所述目标文件;
检查所述目标文件的所述最后访问时间是否有效;
响应于所述最后访问时间有效,根据所述最后访问时间,确定对所述目标文件中的过期文件。
5.根据权利要求4所述的方法,其中,所述检查所述目标文件的所述最后访问时间是否有效包括:
检查所述监控通知机制是否开启;
响应于所述监控通知机制已开启,判断当前时间与监控开始时间之间的第一差值是否大于预设过期阈值;
若所述第一差值大于所述预设过期阈值,确定所述最后访问时间有效;
若所述第一差值不大于所述预设过期阈值,确定所述最后访问时间无效。
6.根据权利要求1-5中任意一项所述的方法,其中,所述根据所述最后访问时间,确定所述目标文件中的过期文件包括:
获取所述目标文件的最后修改时间;
将所述最后访问时间与所述最后修改时间进行对比;
响应于所述最后访问时间晚于所述最后修改时间,计算当前时间与所述最后访问时间之间的第二差值,确定所述第二差值大于预设过期阈值的所述目标文件为所述过期文件;
响应于所述最后访问时间早于所述最后修改时间,计算所述当前时间与所述最后修改时间之间的第三差值,确定所述第三差值大于所述预设过期阈值的所述目标文件为所述过期文件。
7.根据权利要求1-6中任意一项所述的方法,所述文件清理机制的触发流程包括:
响应于应用程序冷启动达到第一预设时间或所述应用程序返回前台,并在所述应用程序满足文件清理条件时,触发所述文件清理机制;
其中,所述应用程序满足所述文件清理条件包括:当前时间与上一次文件清理时间之间的第四差值达到预设清理阈值,并且满足所述应用程序覆盖升级或用户磁盘状态发生变动。
8.一种文件清理装置,包括:
文件监控模块,被配置为调用监控通知机制对目标文件进行监控;
文件时间更新模块,被配置为响应于所述目标文件发生监控事件,对所述目标文件的所述最后访问时间进行更新;
获取模块,被配置为响应于文件清理机制被触发,获取每个所述目标文件的最后访问时间;
确定模块,被配置为根据所述最后访问时间,确定所述目标文件中的过期文件;
文件清理模块,被配置为对所述过期文件进行清理。
9.根据权利要求8所述的装置,其中,所述调用监控通知机制对目标文件进行监控包括:
在Java层添加单个文件或创建包括多个文件的目标文件目录作为所述目标文件;
利用所述Java层的Java本地接口调用所述监控通知机制,通过所述监控通知机制对所有所述目标文件进行监控;
响应于所述目标文件发生所述监控事件,通过所述Java本地接口回调,将所述监控事件对应的信息写入所述目标文件对应的文件描述符。
10.根据权利要求8所述的装置,其中,所述监控事件包括打开事件或访问事件;所述文件时间更新模块响应于所述目标文件发生监控事件,对所述目标文件的所述最后访问时间进行更新包括:
响应于所述目标文件发生所述打开事件或所述访问事件,对所述目标文件的所述最后访问时间进行更新。
11.根据权利要求8-10中任意一项所述的装置,所述确定模块根据所述最后访问时间,确定所述目标文件中的过期文件包括:
遍历单元,被配置为遍历目标文件;
检查单元,被配置为检查所述目标文件的所述最后访问时间是否有效;
确定单元,被配置为响应于所述最后访问时间有效,根据所述最后访问时间,确定对所述目标文件中的过期文件。
12.根据权利要求11所述的装置,其中,所述确定单元检查所述目标文件的所述最后访问时间是否有效包括:
检查所述监控通知机制是否开启;
响应于所述监控通知机制已开启,判断当前时间与监控开始时间之间的第一差值是否大于预设过期阈值;
若所述第一差值大于所述预设过期阈值,确定所述最后访问时间有效;
若所述第一差值不大于所述预设过期阈值,确定所述最后访问时间无效。
13.根据权利要求8-12中任意一项所述的装置,其中,所述确定模块根据所述最后访问时间,确定所述目标文件中的过期文件包括:
获取所述目标文件的最后修改时间;
将所述最后访问时间与所述最后修改时间进行对比;
响应于所述最后访问时间晚于所述最后修改时间,计算当前时间与所述最后访问时间之间的第二差值,确定所述第二差值大于预设过期阈值的所述目标文件为所述过期文件;
响应于所述最后访问时间早于所述最后修改时间,计算所述当前时间与所述最后修改时间之间的第三差值,确定所述第三差值大于所述预设过期阈值的所述目标文件为所述过期文件。
14.根据权利要求8-13中任意一项所述的装置,还包括:
触发模块,被配置为响应于应用程序冷启动达到第一预设时间或所述应用程序返回前台,并在所述应用程序满足文件清理条件时,触发所述文件清理机制;
其中,所述应用程序满足所述文件清理条件包括:当前时间与上一次文件清理时间之间的第四差值达到预设清理阈值,并且满足所述应用程序覆盖升级或用户磁盘状态发生变动。
15.一种电子设备,包括:
至少一个处理器;以及
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行权利要求1-7中任一项所述的方法。
16.一种存储有计算机指令的非瞬时计算机可读存储介质,其中,所述计算机指令用于使所述计算机执行根据权利要求1-7中任一项所述的方法。
17.一种计算机程序产品,包括计算机程序,所述计算机程序在被处理器执行时实现根据权利要求1-7中任一项所述的方法。
CN202310337842.5A 2023-03-31 2023-03-31 文件清理方法、装置、电子设备及存储介质 Pending CN116431578A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310337842.5A CN116431578A (zh) 2023-03-31 2023-03-31 文件清理方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310337842.5A CN116431578A (zh) 2023-03-31 2023-03-31 文件清理方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
CN116431578A true CN116431578A (zh) 2023-07-14

Family

ID=87091931

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310337842.5A Pending CN116431578A (zh) 2023-03-31 2023-03-31 文件清理方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN116431578A (zh)

Similar Documents

Publication Publication Date Title
CN111090536B (zh) 一种获取内存泄露信息的方法、装置、介质和电子设备
EP2674868A1 (en) Database update notification method
CN111078418B (zh) 操作同步方法、装置、电子设备及计算机可读存储介质
CN117573331A (zh) 内存控制方法、装置、设备及介质
CN116545905A (zh) 一种服务健康检测方法、装置、电子设备及存储介质
CN116431578A (zh) 文件清理方法、装置、电子设备及存储介质
CN113676531B (zh) 电商流量削峰方法、装置、电子设备及可读存储介质
CN115310096A (zh) 一种安全漏洞的处理方法、装置、设备及介质
CN115617800A (zh) 数据读取方法、装置、电子设备及存储介质
CN115883647A (zh) 业务日志记录方法、***、装置、终端、服务器及介质
CN115580522A (zh) 一种容器云平台运行状态的监控方法及装置
CN112925675B (zh) 用于小程序的恢复方法和装置
CN114462030A (zh) 隐私政策的处理、取证方法、装置、设备及存储介质
CN112261072B (zh) 一种服务调用方法、装置、设备和存储介质
CN113886473A (zh) 一种提供业务数据的方法及装置
CN113110846A (zh) 一种环境变量的获取方法及装置
CN112860235A (zh) 处理文本的方法、装置、设备和存储介质
CN113760315A (zh) 测试***的方法和装置
CN116340102B (zh) 一种内存溢出监测方法、装置、设备及存储介质
CN110784479B (zh) 一种数据校验方法、装置、电子设备及存储介质
CN113595870B (zh) 推送消息的处理方法、装置、电子设备及存储介质
CN114253633A (zh) 接口调用方法、装置、电子设备以及存储介质
CN118132109A (zh) 软件开发工具包的发布方法、装置、设备及介质
CN115878086A (zh) 一种应用程序的运行处理方法、装置、设备及存储介质
JP2023022843A (ja) 故障情報ポジショニング方法、装置、機器及び記憶媒体

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination