OSDev.org

don't ask why ... today a friend of mine just forgot "stuff/" before her "rm * -rf" command ... and she of course lost everything valuable on her disk ...

No problemo did i say: i'll find a way to recover things... and indeed i found several stuff to undelete files on a Linux system (including, but not limited to "recover", "mc -> Options -> Undelete files" and "debugfs" ...

But all those tools had the same limitation : they couldn't recover anything on her EXT3 partition ... while for the sake of journalizing your metadata changes, EXT3 simply erases any list of data blocks with zeroes when a file is ReMoved ... while EXT2 simply tagged those blocks as "free for use".

to my best knowledge, none of the existsing journalized filesystems have any undelete support (i mean, once you command the file to be removed, the probability an automated system recovers the file is indeed 0).

And they said "there is no need for Yet Another FileSystem" ...

There isn't - undelete functionality should be in the hands of the OS. (Can you say "trashcan"?)

Pype.Clicker wrote: don't ask why ... today a friend of mine just forgot "stuff/" before her "rm * -rf" command ... and she of course lost everything valuable on her disk ...

No problemo did i say: i'll find a way to recover things... and indeed i found several stuff to undelete files on a Linux system (including, but not limited to "recover", "mc -> Options -> Undelete files" and "debugfs" ...

But all those tools had the same limitation : they couldn't recover anything on her EXT3 partition ... while for the sake of journalizing your metadata changes, EXT3 simply erases any list of data blocks with zeroes when a file is ReMoved ... while EXT2 simply tagged those blocks as "free for use".

to my best knowledge, none of the existsing journalized filesystems have any undelete support (i mean, once you command the file to be removed, the probability an automated system recovers the file is indeed 0).

And they said "there is no need for Yet Another FileSystem" ...

Well there is one I think, NTFS, well at lease you can undelete files that were enptied from the Recycle bin.

srg

Solar wrote: There isn't - undelete functionality should be in the hands of the OS. (Can you say "trashcan"?)

The way in which current filesystems "implement" file undeletion is more of a flaw than a feature. Because it's simpler to just mark the first byte than to delete the entire contents filesystems mark the first byte. If you thus know the first byte, you can probably recover the file (save for fragmented files). However, the filesystem was never designed to allow undeleting..

I can say trashcan, but it's a bad design. If your disk is 90% full installers crap out, because the remaining 10% goes to the trashcan. Now, if the trashcan were to auto-empty itself, it would function properly. Also, moving files to a different directory doesn't give the user the feeling it's deleted.

In my FS, the "deleted" files still remain, until there is a need to actually delete a file for space. Not only does it save against errors like this, it also saves against intentional malware & stuff, and it doesn't waste a bit of space.

i was thinking at placing "personnalities" on directories & files ... Some of your directories (for instance those which the user commanded directly to the shell) will automatically have the "precious files" personnality and a "remove" request would have a trashcan-like effect. I was also thinking of keeping the list of blocks apart so that one could be sure it will only be freed when all the other blocks of the file have been freed.

Directories created by software installers, unarchivers, etc. are not precious. Files contained there are (normally) recoverable from some external source (which the directory itself could remember so that 'recover <filename>' under a tarzxvf-created directory will try to locate the archive again and restore the file out of it

Once a user opens a file with an editor and write it back, the file becomes "precious" aswell... Probably you'll find it nice if you can undelete the makefile you patched for hours while you certainly don't care for all the .o files generated during compilation nor for the .c files that came straight out of the box.

Candy wrote:
I can say trashcan, but it's a bad design.

I said "trashcan", not "Windows trashcan". Same as with when someone mentions "registry". Don't blame the design for Microsoft's bad implementation.

What's so special about linux's trashcan compaired to windows then?

srg

::)

What kind of logic did make you believe I was referring to the Linux trashcan just because I am not talking about the Windows trashcan?

This world is not binary, you know?

OK, I'll elaborate.

The capability to undo a file deletion is something that has to be supported by the operating system. Even if your filesystem has some kind of "direct" support for it - like a flag for "marked for deletion since" and some implied logic to erase the oldest marked files when drive space gets low - you still need some user interface to allow the user to select which deletions to undo.

So, the details of the UI are in OS land. At that point you should ask yourself, what keeps you from providing the same UI logic regardless of the file system? Move files to /trashcan, or set a "deleted" flag, or use some internal bookkeeping, or whatever - there is no really good reason why such support should be limited to some to-be-created file system (which happens to be a non-option to user A because it lacks X), instead of being generally useable regardless of whether it's on your ReiserFS boot partition, your shared FAT32 partition, or Whatever (tm).

Note how I did not talk about the details of the UI itself. It doesn't matter. It's not an UI decision but a technical one. If you don't like the Windows Trashcan or the Linux Trashcan or the AmigaOS Trash, come up with a better UI, but it has nothing to do with the filesystem.

IMNSHO, but I'd like to hear if a good reason exists for Undelete to be tied to the FS.

i'd be tempted to say lx implementation (afaik) is even worse ... i 've never seen a tool that allowed to set up maximal trash size in Linux ... and none of the OS i saw was able to cope with *replaced* files (e.g delete accidentally document A by wrongly renaming document B ...

Solar wrote: The capability to undo a file deletion is something that has to be supported by the operating system. Even if your filesystem has some kind of "direct" support for it - like a flag for "marked for deletion since" and some implied logic to erase the oldest marked files when drive space gets low - you still need some user interface to allow the user to select which deletions to undo.

....

IMNSHO, but I'd like to hear if a good reason exists for Undelete to be tied to the FS.

How can you cleanly implement auto-freeing deleted files if the filesystem doesn't know which files are deleted? (note that this is exactly what I think wrong of the Trashcandesign).

Note how I did not talk about the details of the UI itself. It doesn't matter. It's not an UI decision but a technical one. If you don't like the Windows Trashcan or the Linux Trashcan or the AmigaOS Trash, come up with a better UI, but it has nothing to do with the filesystem.

No problem with this stuff, but the problem I have is the TRASHCAN design. The design should not be a trashcan that moves your files. If I say delete, the computer should say delete. Not move.

By deleting files in the filesystem you leave the task of administering files and locations to - the file system. Wonder what file system stands for again...

Candy wrote:No problem with this stuff, but the problem I have is the TRASHCAN design. The design should not be a trashcan that moves your files. If I say delete, the computer should say delete. Not move.

I agree totally.

At least in windows you can turn it off (can you do that in linux)?

srg

I have to go in the opposite direction; one of the principles of the Xanadu system (which is a major inspiration for my own work) is that data should never be permanently destroyed. Mind you, the Xanadu system was designed from the first to be distributed; applications and non-local data would only be cached locally, and the storage system was designed so as to minimize redundancy (at least in principle) by linking to repeated data rather than copying it. See Project Xanadu for details.

Of course, one could point out that after 40 years, it still isn't working, which is certainly reason enough to question the underlying concepts. Still, I would have to say that, under most circumstances, data retention is more valuable than disk space. 'Lazy Deletion' is a Good Thing.

IMO, the best filesystem is not the one that can offer undeletion capability or max space, but the one that has the best of both (or simply both). The windows-approach offers undeletion, turning it off gives me max space. I want my files to be reserved until the space they take is required for something else. If my harddisk is 60GB, I delete 5MB and then write 40GB, there is /NO/ reason the 5MB should not be available. When I have 10MB free, I delete 50MB of files (to the trash can, just normal plain delete), and I place a 30M file on the disk it should work and not complain of too little free space.

Principle of least surprise. And, the first one is the data retention idea, which is also a very good idea (accidental deletes s*ck).

Candy wrote: How can you cleanly implement auto-freeing deleted files if the filesystem doesn't know which files are deleted?

The "not enough space" message is reported by the file system. The OS is free to intercept that message before it gets passed to the user-space application, and apply "cleanup" functions first (like, moving the oldest files out of the trashcan into digital nirvana). Then retry the file operation.

This is just a shot from the hip. What's so difficult about it?

No problem with this stuff, but the problem I have is the TRASHCAN design. The design should not be a trashcan that moves your files. If I say delete, the computer should say delete. Not move.

Remember that, back in the 80ies, the idea was the "desktop metaphor". If you have a paper you no longer need, you but it in the bin. If you change your mind, you take it out of the bin again. If your bin is full, you empty it.

Add to that concept a bin that automatically takes out a bit of trash as it gets too full (so you no longer have to worry about it), and you're quite there.

As to "when I say delete, I mean delete"... read Pype's initial post again. Sometimes we don't mean what we say. Sometimes the computer understands something different than we say. Sometimes we change our mind. I certainly want an undelete. The more transparent, the better.

Another example. I am using Directory Opus as replacement for Windows Explorer. There's "File" - "Edit" - "View"..., and the top entry in "Edit" is named "Undo". It's even accessed with Ctrl-Z, just as in my favourite text editor. I can undo file deletions, file moves, file renames, lots of stuff. All that Opus does is adding a different UI to the Windows Trashcan. D'oh.

Solar wrote:

Candy wrote: How can you cleanly implement auto-freeing deleted files if the filesystem doesn't know which files are deleted?

The "not enough space" message is reported by the file system. The OS is free to intercept that message before it gets passed to the user-space application, and apply "cleanup" functions first (like, moving the oldest files out of the trashcan into digital nirvana). Then retry the file operation.

This is just a shot from the hip. What's so difficult about it?

That you're percolating the function of file management to the user environment, making it less obvious and most certainly less a feature of the operating system. Which in the end comes down to most programs doing things that are not compliant, or simply passing by your layers. Having the OS intercept a message when it could "intercept" the message at the layer where it is both created and processed (in the end), seems like an excessive load.

Remember that, back in the 80ies, the idea was the "desktop metaphor". If you have a paper you no longer need, you but it in the bin. If you change your mind, you take it out of the bin again. If your bin is full, you empty it.

Add to that concept a bin that automatically takes out a bit of trash as it gets too full (so you no longer have to worry about it), and you're quite there.

The point of the trashbin was not to make a new place for old files. The point of the trashbin was to make it possible for users to not actually delete files. It's like an archive, not like a trashbin. If you want something back from the trashbin it's not in mint condition (at least not in my trash bins). The trashbin as you propose it is more like a separate space on the desktop.

As to "when I say delete, I mean delete"... read Pype's initial post again. Sometimes we don't mean what we say. Sometimes the computer understands something different than we say. Sometimes we change our mind. I certainly want an undelete. The more transparent, the better.

Another example. I am using Directory Opus as replacement for Windows Explorer. There's "File" - "Edit" - "View"..., and the top entry in "Edit" is named "Undo". It's even accessed with Ctrl-Z, just as in my favourite text editor. I can undo file deletions, file moves, file renames, lots of stuff. All that Opus does is adding a different UI to the Windows Trashcan. D'oh.

The point of that directory opus is that it has "features" that it only has because the OS was too reluctant to implement them at the place where they would logically be done. If the filesystem (+ driver) cannot make a best-effort, I cannot use the filesystem. Saying as the function is still there, but in the place of some other tool, that's just bad design. You should recognise that.