Can anybody know whether it is possible to delete the file to which the stream of information goes, i.e. the file is open for writing by another application, but I need to reset it in Unix / Linux at some specific time.

check echo> file echo -n> file head -c 0> file cat / dev / null> file

ramp is not reset!

  • Yes, of course not reset. For the reasons just described by me below. - cy6erGn0m

4 answers 4

If the file is not locked (usually it is not done), then it can be easily deleted. However, the disappearance of the file from the file tree will not mean its actual deletion. In fact, the file will exist until the application that writes to it closes it. At the same time, the file will no longer be open. In this intermediate state, he will continue to occupy disk space. I'm not sure that this behavior is reproduced on all file systems, but under ext3 I precisely watched this.

PS: thus, the answer to your question: after all, this is a bad idea and you should refrain from this. Moreover, it will definitely not be portable to other platforms (such as Windows).

UPD: answer for rtfm

lsof takes the file name as input, and once a file is deleted, there is no file either. Therefore, lsof will say that the file is not found. But in fact, the file body still exists, although there are no longer any links to it from the file tree.

Check the guess:

cy6ergn0m@cgmachine ~ $ cat - > ~/delete & [1] 22129 cy6ergn0m@cgmachine ~ $ [1] + suspended (tty input) cat - > ~/delete cy6ergn0m@cgmachine ~ $ /usr/sbin/lsof ~/delete COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME cat 21808 cy6ergn0m 1w REG 8,7 0 19128453 /home/cy6ergn0m/delete cy6ergn0m@cgmachine ~ $ rm -f ~/delete cy6ergn0m@cgmachine ~ $ /usr/sbin/lsof ~/delete lsof: status error on /home/cy6ergn0m/delete: No such file or directory lsof 4.83 latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/ latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man usage: [-?abhlnNoOPRtUvVX] [+|-cc] [+|-ds] [+DD] [+|-f[gG]] [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+m [m]] [+|-M] [-o [o]] [-ps] [+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-us] [+|-w] [-x [fl]] [--] [names] Use the ``-h'' option to get more help information.
  • spit! I just need to reset it! it's just that the video stream is written here, I just need to drop its size! - alexeych
  • Then we must understand that: a) the video stream will continue to be written into the old, already “invisible” file; b) it will be possible to create a new file in place of the old one, but both of them will take up disk space. Thus, success is possible only partially. For example, it is not clear how you will continue to record the video in a new file, if there is already a process that writes to the old one .. then you will have to kill it anyway and launch a new one. - cy6erGn0m
  • So in this case, it is necessary not to delete the file and reset! That it will be written there it is clear! But how to make it so that he just threw the size! - alexeych
  • You can't do it outside. It is necessary to force the application itself to do this. It’s like log rotation. You can not just take and change the log file from the application. It is necessary that the logger of the application itself did all this. - cy6erGn0m
  • I don’t already understand the details, but it seems that the file is simply deleted, and the node remains and the association of the node with the process appears somewhere. - cy6erGn0m

If an application opens a file named File for writing with O_APPEND, then> File in sh will cut the file (ls -l will show it).

Otherwise, the size shown by ls -l will not decrease. However, if the file size (at the moment>) is larger than the file system block size (usually 4 or 8 Kbyte), then du File will show the reduction of the file.

The point is this: When we open a file with a file descriptor, the position in the file with which the recording is being made is connected. It (position) grows with each write (). This data belongs to the process that opened the file. When another process does truncate (), the file size in the file system is definitely reduced (and now the unused data blocks are deleted (more precisely, they are placed on the free list)). However, this does not affect the position of the record in the first process (by the way, even if you do the truncate in it), therefore, with the next write () from the first process, the file length will increase. If at this moment you read the file (for example, cat File> fff from another window), then there will be binary zeros in it (from beginning to last write ()).

Opening a file with O_APPEND modifies the behavior — for each write (), the write position shifts to the end of the file according to its current size in the file system.

I hope this is true for most Unix / Linux. In the emulator did not check.

  • ADMIN: Totally confused with what data to enter with which company. Send me (avp), please, sensible instructions on avp210159@mail.ru If I forgot the password, how to renew it? - avp

I give a free idea:

Create a named pipe on disk (named pipe) ( mkfifo ). One end of the channel pokes into the program that wants to write a video stream. At the other end you hang up your program (and, surely, there is a ready-made solution), which will open the real file and stupidly the entire stream from the channel will write to it, and re-open the file using some signal (well, like SIGHUP, as is customary).

  • How is this different from writing to / dev / null? - alexlz
  • @alexlz Sorry, uh ... well ... I didn't understand what you were talking about :( - kirelagin
  • He suggests that the application write not to a real file, but through a special adapter channel. This will work if the data is really 100% streaming and if the program itself is not dead yet for some reason. Then this channel can be redirected to different files or at some point do a reset. - cy6erGn0m
  • About the proposal is clear. It is not clear how this differs from the record "to nowhere." Is that the fact that the tail can still be read. But this is a question for the author of the original question. - alexlz
  • @alexlz something, in my opinion, after all, something is not clear ... Do you even catch, what is the problem raised in the question? - kirelagin

Your_file in bash doesn't help? In general, the standard question once for beginners unixoids "How to clean the logs?" That is any truncate.

And the user cannot delete the file in unix-like, it can only delete the inode of this file in the disk (unlink operation). When opening a file, an inode is created in the kernel and exists before closing. The system deletes files, provided that no inode is referenced to the file (either from disk or from kernel tables)

  • Not. All the way around. The inode is the body of the file. And link to it. This inode has a usage count and references to it the elements of the file tree. unlink breaks the connection between the file system tree and the inode, and when the counter goes to zero, the body is also deleted. However, in general, it is true - the old process will work with the old body even if you "delete" the file. If you create a new one, a new inode (new file body) and a new connection will appear. - cy6erGn0m
  • Your_file It’s written in the question that it didn’t help. Although, in fact, it can sometimes help. For example, if cat writes this to a file, you can reduce it with another cat. But this does not work with all applications. I think this is due to the recording modes: stream append or random access edit + append. - cy6erGn0m
  • Shame on me. Apparently then not yet awake. - alexlz
  • The directory, in secret, also corresponds to a disk inode, and unlink only removes the file entry from there, so it becomes inaccessible for access by name. When opening a file, the link to it is saved in the fdtable process until the corresponding descriptor is open, that is, the process is alive and does not close the file itself. Physically, disk blocks are freed after all the descriptors referring to a file are closed, quite asynchronously depending on the file system, and usually truncate () contributes to this. - rtfm
  • All this is really strange, because truncate () changes the size of files, even with ordinary (non-mandatory) lock'ov. - rtfm