Incoming from Jan Minar:
> On Mon, Feb 16, 2004 at 12:25:08AM +0100, Martin Dickopp wrote:
> >
> > Yes, /proc is quite different from other filesystems in many ways. :)
>
> Is it documented? I wasn't able to find anything. Particularly,
Anything? You didn't install man pages? "man proc" work
On Mon, Feb 16, 2004 at 12:25:08AM +0100, Martin Dickopp wrote:
> Tim Otten <[EMAIL PROTECTED]> writes:
> > OMG. That does work. I didn't try it because the file looks like a symlink
> > in 'ls' -- a similar process with symlinks on a normal filesystem will
> > produce different results:
>
> Yes,
Tim Otten <[EMAIL PROTECTED]> writes:
>> /proc/PID/fd seems to work just fine; see transcript below.
>
> OMG. That does work. I didn't try it because the file looks like a symlink
> in 'ls' -- a similar process with symlinks on a normal filesystem will
> produce different results:
Yes, /proc is q
> /proc/PID/fd seems to work just fine; see transcript below.
OMG. That does work. I didn't try it because the file looks like a symlink
in 'ls' -- a similar process with symlinks on a normal filesystem will
produce different results:
[EMAIL PROTECTED]:/tmp$ echo This is a test > t.txt
[EMAIL PRO
On Sun, Feb 15, 2004 at 02:03:06PM -0500, Tim Otten wrote:
> file (because the filesystem was mounted, and the man page doesn't say
> whether it's safe to edit a live filesystem), but the 'dump' command worked
> fine in a test that I just did.
It's not. You did it the most right way.
--
Jan Min
On Sun, Feb 15, 2004 at 12:11:18PM -0700, s. keeling wrote:
> However, that's just standard *nix filesystem behaviour. You can rm
> 'til the cows come home, but as long as one symlink to the data
> remains, the data remains as well.
Hard link not symlink :)
Bijan
--
Bijan Soleymani <[EMAIL PROT
> (1) debugfs(8) or equivalent
Ah! debugfs looks perfect. I probably couldn't have added an entry for the
file (because the filesystem was mounted, and the man page doesn't say
whether it's safe to edit a live filesystem), but the 'dump' command worked
fine in a test that I just did.
> (2) inject
Incoming from Martin Dickopp:
> Tim Otten <[EMAIL PROTECTED]> writes:
>
> > The other day, I did something really stupid. I started a download with
> > BitTorrent, and, half-way through, deleted the file it was downloading.
>
> [EMAIL PROTECTED]:~ > echo This is a test. > t.txt
> [EMAIL PROTECTED
On Sun, Feb 15, 2004 at 10:41:41AM -0800, Paul Johnson wrote:
> On Sun, Feb 15, 2004 at 09:20:55AM -0500, Tim Otten wrote:
> > The other day, I did something really stupid. I started a download with
> > BitTorrent, and, half-way through, deleted the file it was downloading.
>
> > Is it possible to
Tim Otten <[EMAIL PROTECTED]> writes:
> The other day, I did something really stupid. I started a download with
> BitTorrent, and, half-way through, deleted the file it was downloading.
>
> The file still existed because the torrent client had it open. I could use
> 'lsof' to get an inode number -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Feb 15, 2004 at 09:20:55AM -0500, Tim Otten wrote:
> The other day, I did something really stupid. I started a download with
> BitTorrent, and, half-way through, deleted the file it was downloading.
> Is it possible to access the file using a
On Sun, Feb 15, 2004 at 09:20:55AM -0500, Tim Otten wrote:
> The other day, I did something really stupid. I started a download with
> BitTorrent, and, half-way through, deleted the file it was downloading.
>
> The file still existed because the torrent client had it open. I could use
> 'lsof' to
The other day, I did something really stupid. I started a download with
BitTorrent, and, half-way through, deleted the file it was downloading.
The file still existed because the torrent client had it open. I could use
'lsof' to get an inode number -- but I needed some way to get access to
that no
13 matches
Mail list logo
