4 ms·

The program which created the file was running all the time, before I created the zip, during the zip creation, after the zip creation ended, and after I delete

by 323 4y ago

The program which created the file was running all the time, before I created the zip, during the zip creation, after the zip creation ended, and after I deleted the file. The zip creation and me deleting the file were in parallel with another process writing to the file. And I didn't delete the zip file, I deleted the original file that I zipped.

trelane 4y ago
> I didn't delete the zip file, I deleted the original file that I zipped. This is why you should always check the contents of your archive before deleting the originals. There are myriad reasons why the archive may be incomplete or incorrect. You were hit by one of them that happens to not happen on Windows.
Karellen 4y ago
> And I didn't delete the zip file, I deleted the original file that I zipped. OK, I think that's where a lot of the confusion comes from. When you originally said "I zipped a file and deleted it, but the process which created it was still writing to it.", I thought the "it"s referred to the zip file, not the original file, and "the process that created it" was the zip process. Going by your actual meaning - are you saying you zipped a file on disk that was still being written to? That's... weird. Given that reading from disk is faster than writing to it, and the written data may well have been in the disk cache anyway, it's likely that the zip program could have "caught up" with the program that was writing the data, tried another read and been told "this is the end of the file", and then finished creating the zip file. That would have created an incomplete zip. But also, as others have pointed out, just because you delete a file and it gets removed from the directory, the actual file and its contents stay around until all open handles to it are gone. So if one process has the file open and is writing to it, and a second process has the file open and is reading from it, if you delete the file then both processes should still be able to access it through their existing file handles, even though it doesn't have a directory entry any more. So you shouldn't have experienced any data loss from that series of events. (And that's why having the "it"s refer to the zip file is a logical interpretation of what you said, and why a few repliers - including me! - seem confused)
- 323 4y ago
  > Going by your actual meaning - are you saying you zipped a file on disk that was still being written to? That's... weird. That's how Linux works. Some programs, like rsync, will give you a warning at the end, similar to "the file was modified during the rsync operation". Most others, like zip will give no warning at all.
  - Karellen 4y ago
    Sorry, I wasn't clear. I didn't mean it was weird that Linux would be able to do that. I meant I thought it was weird that a user would choose to do that. Because without any co-ordinated locking in place, or double-checking at the end (which most won't unless it's been specifically added), having one program read a file while another is modifying it will most probably produce confusing or unexpected results.

by 323 4y ago

trelane 4y ago

> I didn't delete the zip file, I deleted the original file that I zipped. This is why you should always check the contents of your archive before deleting the originals. There are myriad reasons why the archive may be incomplete or incorrect. You were hit by one of them that happens to not happen on Windows.

Karellen 4y ago

> And I didn't delete the zip file, I deleted the original file that I zipped. OK, I think that's where a lot of the confusion comes from. When you originally said "I zipped a file and deleted it, but the process which created it was still writing to it.", I thought the "it"s referred to the zip file, not the original file, and "the process that created it" was the zip process. Going by your actual meaning - are you saying you zipped a file on disk that was still being written to? That's... weird. Given that reading from disk is faster than writing to it, and the written data may well have been in the disk cache anyway, it's likely that the zip program could have "caught up" with the program that was writing the data, tried another read and been told "this is the end of the file", and then finished creating the zip file. That would have created an incomplete zip. But also, as others have pointed out, just because you delete a file and it gets removed from the directory, the actual file and its contents stay around until all open handles to it are gone. So if one process has the file open and is writing to it, and a second process has the file open and is reading from it, if you delete the file then both processes should still be able to access it through their existing file handles, even though it doesn't have a directory entry any more. So you shouldn't have experienced any data loss from that series of events. (And that's why having the "it"s refer to the zip file is a logical interpretation of what you said, and why a few repliers - including me! - seem confused)

323 4y ago
> Going by your actual meaning - are you saying you zipped a file on disk that was still being written to? That's... weird. That's how Linux works. Some programs, like rsync, will give you a warning at the end, similar to "the file was modified during the rsync operation". Most others, like zip will give no warning at all.
- Karellen 4y ago
  Sorry, I wasn't clear. I didn't mean it was weird that Linux would be able to do that. I meant I thought it was weird that a user would choose to do that. Because without any co-ordinated locking in place, or double-checking at the end (which most won't unless it's been specifically added), having one program read a file while another is modifying it will most probably produce confusing or unexpected results.