4 ms·

You stat() all the files, they look empty, so you delete them... but in between, another process writes to some file (or maybe the user forgets the file is bein

by yason 8y ago

You stat() all the files, they look empty, so you delete them... but in between, another process writes to some file (or maybe the user forgets the file is being deleted and saves to something there), and suddenly you've deleted data you didn't expect This is fundamentally not any different between the systems, race conditions can happen either way. The user could write data to file right before the deletion recurses to the same directory and the handle-based deletion happens. Similarly the newly written data would be wiped out unintentionally. For files for which access from different processes must be controlled explicitly there is locking. No filesystem or VFS is going to protect you from accidentally deleting stuff you're still using in another context.

mehrdadn 8y ago
> [...] The user could write data to file right before the deletion recurses to the same directory and the handle-based deletion happens. Similarly the newly written data would be wiped out unintentionally. [...] No filesystem or VFS is going to protect you from accidentally deleting stuff you're still using in another context. ...what? No file system is going to protect you from accidentally deleting in-use files? But that's exactly what Windows does: it prevent you from deleting in-use files. That's what everyone here has been complaining about. File sharing modes let you lock files to make sure they're not written to (and/or read from) before being deleted, it very much need not be the case that the user could write to a file before it's deleted.
- yason 8y ago
  Read my comment again. There is an inherent race condition if one program is using a file and another program is deleting it without caring about whether the file is being accessed by other programs. At that point, all bets are off there regardless of whether the files are accessed by paths or handles. Windows protects the file from deletion at the exact same time as it is being accessed but does not protect the file from being deleted after it has been accessed. In wall-clock statistics the latter is the way more likely scenario. So, if an editor saves a document to disk, and another program then deletes the document the editor will happily exit without saving it again thinking that it hasn't been changed. It doesn't particularly matter whether the two programs clash exactly at the time of saving/deletion or not. The problem exists in the lack of information between the programs and no file system is indeed going to protect you from that.
  - mehrdadn 8y ago
    > So, if an editor saves a document to disk, and another program then deletes the document the editor will happily exit without saving it again thinking that it hasn't been changed. I'm trying to explain to you that your understanding of Windows is wrong and that this is impossible. As long as that editor has the document open, unless it has explicitly specified FILE_SHARE_WRITE and FILE_SHARE_DELETE, Windows will not allow another program to alter that file. So the editor would very rightly assume upon exiting that nobody has touched that file while it's had that file open.
    - yason 8y ago
      I know how opening a file affects the exclusivity of access but commonly applications don't seem to keep the file continuously open except during reading or writing. Maybe some Microsoft applications use that pattern extensively but it generally works to save a file in one program and then open it in another program without closing the file in the first program or quitting it. Nevertheless, this is getting off topic as the thread started with the question of path vs handle access. I still don't see much value in this exclusivity in the latter case because if you have a conflict to begin with it's just a matter of Murphy's for that conflict to manifest in actually losing data. Even if your editor keeps the file open for the whole day, and you have this second program that is on the trajectory to delete the file it will eventually get to it at a time when the file is not open and thus not protected by the guarantee of exclusive access.
int_19h 8y ago
> This is fundamentally not any different between the systems, race conditions can happen either way. The user could write data to file right before the deletion recurses to the same directory and the handle-based deletion happens. When you hold a handle to a file or directory, you get to decide on the degree of shared access with any other users for the duration that handle is held (FILE_SHARE_*). So this does solve the concurrency problem, by allowing you to, effectively hold a lock on the file until you're done.

by yason 8y ago

mehrdadn 8y ago

> [...] The user could write data to file right before the deletion recurses to the same directory and the handle-based deletion happens. Similarly the newly written data would be wiped out unintentionally. [...] No filesystem or VFS is going to protect you from accidentally deleting stuff you're still using in another context. ...what? No file system is going to protect you from accidentally deleting in-use files? But that's exactly what Windows does: it prevent you from deleting in-use files. That's what everyone here has been complaining about. File sharing modes let you lock files to make sure they're not written to (and/or read from) before being deleted, it very much need not be the case that the user could write to a file before it's deleted.

yason 8y ago
Read my comment again. There is an inherent race condition if one program is using a file and another program is deleting it without caring about whether the file is being accessed by other programs. At that point, all bets are off there regardless of whether the files are accessed by paths or handles. Windows protects the file from deletion at the exact same time as it is being accessed but does not protect the file from being deleted after it has been accessed. In wall-clock statistics the latter is the way more likely scenario. So, if an editor saves a document to disk, and another program then deletes the document the editor will happily exit without saving it again thinking that it hasn't been changed. It doesn't particularly matter whether the two programs clash exactly at the time of saving/deletion or not. The problem exists in the lack of information between the programs and no file system is indeed going to protect you from that.
- mehrdadn 8y ago
  > So, if an editor saves a document to disk, and another program then deletes the document the editor will happily exit without saving it again thinking that it hasn't been changed. I'm trying to explain to you that your understanding of Windows is wrong and that this is impossible. As long as that editor has the document open, unless it has explicitly specified FILE_SHARE_WRITE and FILE_SHARE_DELETE, Windows will not allow another program to alter that file. So the editor would very rightly assume upon exiting that nobody has touched that file while it's had that file open.
  - yason 8y ago
    I know how opening a file affects the exclusivity of access but commonly applications don't seem to keep the file continuously open except during reading or writing. Maybe some Microsoft applications use that pattern extensively but it generally works to save a file in one program and then open it in another program without closing the file in the first program or quitting it. Nevertheless, this is getting off topic as the thread started with the question of path vs handle access. I still don't see much value in this exclusivity in the latter case because if you have a conflict to begin with it's just a matter of Murphy's for that conflict to manifest in actually losing data. Even if your editor keeps the file open for the whole day, and you have this second program that is on the trajectory to delete the file it will eventually get to it at a time when the file is not open and thus not protected by the guarantee of exclusive access.

int_19h 8y ago

> This is fundamentally not any different between the systems, race conditions can happen either way. The user could write data to file right before the deletion recurses to the same directory and the handle-based deletion happens. When you hold a handle to a file or directory, you get to decide on the degree of shared access with any other users for the duration that handle is held (FILE_SHARE_*). So this does solve the concurrency problem, by allowing you to, effectively hold a lock on the file until you're done.