Opened 15 years ago
Closed 2 years ago
#4012 closed bug (fixed)
NTFS handles deletions incorrectly
| Reported by: | axeld | Owned by: | 3dEyes |
|---|---|---|---|
| Priority: | critical | Milestone: | R1/beta4 |
| Component: | File Systems/NTFS | Version: | R1/Development |
| Keywords: | Cc: | Jens.Arm@…, alexbl@… | |
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
When a file is unlinked/deleted, you must only make it unavailable to the user (ie. it must not appear in file listings anymore, and cannot be opened).
However, its space on disk must not be deleted until the kernel no longer needs the file (it will then call fs_remove_vnode()). Until that one is called, an application with an open file handle must still be able to read from that file, and write to that file as if it would still exist.
Please check if the file system remains valid when actually doing so - in that case, the priority could be put back to "high". As is, I wouldn't enable read/write for the file system yet.
Change History (12)
comment:1 by , 15 years ago
| Cc: | added |
|---|
follow-up: 3 comment:2 by , 14 years ago
| Cc: | added |
|---|
follow-up: 4 comment:3 by , 14 years ago
| Version: | R1/pre-alpha1 → R1/Development |
|---|
Replying to alexbl:
Is this the same issue that stops you from being able to upgrade a running system? (and thus not ntfs specific)?
No, that would be the missing MAP_COPY semantics, and totally unrelated to this particular problem. The same is true for all major operating systems, anyway (not that I would like it, though).
Another problem is that Haiku will try to reload drivers when you replace them which obviously turns out to be problematic as well in some cases (needs investigation).
follow-up: 5 comment:4 by , 14 years ago
Replying to axeld:
Replying to alexbl:
Is this the same issue that stops you from being able to upgrade a running system? (and thus not ntfs specific)?
No, that would be the missing MAP_COPY semantics, and totally unrelated to this particular problem. The same is true for all major operating systems, anyway (not that I would like it, though).
This NTFS issue?
Another problem is that Haiku will try to reload drivers when you replace them which obviously turns out to be problematic as well in some cases (needs investigation).
Is there a bug for the live-upgrade problem? Seems like it would be good to have one so that there is a place where information about the problem can be gleaned incase someone wants to try and fix it. :)
follow-up: 6 comment:5 by , 14 years ago
Replying to alexbl:
Replying to axeld:
Replying to alexbl:
Is this the same issue that stops you from being able to upgrade a running system? (and thus not ntfs specific)?
No, that would be the missing MAP_COPY semantics, and totally unrelated to this particular problem. The same is true for all major operating systems, anyway (not that I would like it, though).
This NTFS issue?
Of course not. Is it really that hard to parse that paragraph? At least I would have a hard time understanding it that way.
Another problem is that Haiku will try to reload drivers when you replace them which obviously turns out to be problematic as well in some cases (needs investigation).
Is there a bug for the live-upgrade problem? Seems like it would be good to have one so that there is a place where information about the problem can be gleaned incase someone wants to try and fix it. :)
Not that I know of, feel free to report (or look before, as my memory is definitely no replacement for Trac :-)).
follow-up: 7 comment:6 by , 14 years ago
follow-up: 11 comment:10 by , 7 years ago
Replying to 3dEyes:
not yet, but I'm working on it
4 years later... still working?
I have reed the description - why, application is able to write on deleted file?!? WTH? How it's possible any application can delete file opened for writing? This is insanity. I undestand reading (not quite sure - caches, specially for big files) but writing!?!? This is serious bug i see for handling opened files. I know.. Unlocker for Windows but it's named "unlocker" - invalidate handles to opened files then you can do what you want. I undestand VSS, but it's called "snapshot" by very important reason - files consistency, not just one, all of them.
comment:11 by , 7 years ago
Replying to stasinek:
I have reed the description - why, application is able to write on deleted file?!? WTH? How it's possible any application can delete file opened for writing? This is insanity.
Nope, this is just how file handling works in any unix system. For example this allows you to copy a file to a different folder, and rename the destination file or folder while you are copying it.
I undestand reading (not quite sure - caches, specially for big files) but writing!?!? This is serious bug i see for handling opened files.
Nope, see above.
I know.. Unlocker for Windows but it's named "unlocker" - invalidate handles to opened files then you can do what you want. I undestand VSS, but it's called "snapshot" by very important reason - files consistency, not just one, all of them.
Windows works differently, in fact it "locks" a file when you open it.
comment:12 by , 2 years ago
| Milestone: | R1 → R1/beta4 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
This is fixed in the new NTFS driver glue that was merged in hrev55628.
Is this the same issue that stops you from being able to upgrade a running system? (and thus not ntfs specific)?