Ticket #277 (accepted task)
Eraser Unified File Manager
| Reported by: | Joel | Owned by: | Joel |
|---|---|---|---|
| Priority: | major | Milestone: | Eraser 6.1/6.2 |
| Component: | Core | Version: | |
| Keywords: | Cc: | ||
| Processor Architecture: | Blocked By: | ||
| Blocking: | #210, #221 | Operating System: |
Description (last modified by Joel) (diff)
- Allows handling long file names
- Standardize: directory or folder?
- Multithread/Profile? the erase/directory listing
- Merge VolumeInfo? and StreamInfo? classes?
- LockVolume? interface is weird
- We leak a FileHandle? (the exclusive one) in the VolumeInfo? and StreamInfo? classes
- Should we have a callback for FileSystem.DeleteFolder to monitor progress?
- When catching exceptions when erasing files we need to record the filename
Blocking
| Id | Summary | Milestone |
|---|---|---|
| #277 | └ Eraser Unified File Manager | Eraser 6.1/6.2 |
| #210 | └ Eraser not deleting very long filenames, round 3 | Eraser 6.1/6.2 |
| #221 | └ "Dangling pointer" on erasing files with multiple hard links | Eraser 6.1/6.2 |
Blocked by
| Id | Summary | Milestone |
|---|---|---|
| #277 | └ Eraser Unified File Manager | Eraser 6.1/6.2 |
Change History
comment:8 Changed 13 months ago by Joel
Raymond Chen describes one approach to resolving symbolic links to their paths.
comment:9 Changed 12 months ago by Joel
The BCL team describes their stance in http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx
Note: See
TracTickets for help on using
tickets.
Also the manager must be symbolic link/hard link aware. This helps with #221.