jfsfgdfg
Guest
|
 |
« on: November 17, 2007, 04:15:21 PM » |
|
I'm running fSekrit from a BartPE CD. When I try to save a document to a RAM drive I get an error that it can't write the file. It seems that fSekrit needs to write to the original media instead of just to the saved directory/file.
What would also be helpful would be some type of default save dir instead of the program dir.
Thanks - its a great little program.
|
|
|
|
|
Logged
|
|
|
|
|
f0dder
|
 |
« Reply #1 on: November 17, 2007, 04:33:17 PM » |
|
Hm, you should be able to "file->save as" - obviously "file->save" won't work for read-only media. Which version of fSekrit are you using? Or have I yet again screwed something up majorly? 
|
|
|
|
|
Logged
|
 - carpe noctem
|
|
|
jfsfgdfg
Guest
|
 |
« Reply #2 on: November 17, 2007, 04:51:08 PM » |
|
I'm using 1.2. I was using "Save As.." so I could write to a writeable media. I was surprised when I got the error. When I moved fSekrit to the RAM drive and ran it from there everything was good with both a save and save as. It was just running it from the CD that it didn't like.
Thanks.
|
|
|
|
|
Logged
|
|
|
|
|
|
f0dder
|
 |
« Reply #3 on: November 17, 2007, 05:38:36 PM » |
|
Hm, which exact error are you getting? I'm guessing it's " Error saving file!", which (unfortunately!) is a pretty broad error. I'll see if I can duplicate the error from a read-only network share or something... EDIT: Save As works fine from a read-only share, plain "save" gives the errormessage twice though, at least that should be easy to fix 
|
|
|
|
« Last Edit: November 17, 2007, 05:41:28 PM by f0dder »
|
Logged
|
 - carpe noctem
|
|
|
|
Carol Haynes
|
 |
« Reply #4 on: November 17, 2007, 05:41:25 PM » |
|
Does it use any temporary file while writing? In which case it may be trying to write the temporary file to a read only location ... just a thought.
|
|
|
|
|
Logged
|
|
|
|
|
f0dder
|
 |
« Reply #5 on: November 17, 2007, 05:57:15 PM » |
|
Does it use any temporary file while writing? In which case it may be trying to write the temporary file to a read only location ... just a thought.
Nope, doesn't do that. (And I've just checked my current work-in-progress against 1.2-release, haven't made changes to the filesave code since then). When fSekrit saves, it first copies itself (the current running module) to the target file, and then it appends the note data. When a fSekrit note with note data is run, it copies itself to %temp%, and then launches that file as the editor... this was done to be able to save directly (was implemented in 1.2, previous versions did some even nastier copying around  ). So if your .exe on CD has note data in it, the CD shouldn't even be accessed after launching... A "blank" note doesn't do the tempfile-copying though, so when doing "save as" a blank note will read from the CD...
|
|
|
|
|
Logged
|
 - carpe noctem
|
|
|
jfsfgdfg
Guest
|
 |
« Reply #6 on: November 17, 2007, 06:04:11 PM » |
|
Yes that is the error. Very strange that you can't duplicate it. I just tried again using both save and "save as" and trying to save to a RAM drive - same error.
I then moved fSekrit to the RAM drive and it saves fine.
The temporary location idea seems like an idea. I am running my BartPE CD inside a virtual machine where there are no local machine environment variables set. So if this was the case even burning it to a CD on your machine fSekrit would work OK.
Thanks.
P.S. I did notice the double error message on the save just now.
We were editing at the same time. The fSekrit note on the CD is blank.
|
|
|
|
« Last Edit: November 17, 2007, 06:07:54 PM by jfsfgdfg »
|
Logged
|
|
|
|
jfsfgdfg
Guest
|
 |
« Reply #7 on: November 17, 2007, 06:20:17 PM » |
|
I did a FileMon on fsekrit. Here is part of the log. [ copy or print] 3134 5:13:51 PM fSekrit.exe:600 OPEN B:\test23 NOT FOUND Options: Open Directory Access: Traverse 3135 5:13:51 PM fSekrit.exe:600 OPEN B:\test23 NOT FOUND Options: Open Directory Access: Traverse 3136 5:13:51 PM fSekrit.exe:600 OPEN B:\test23 NOT FOUND Options: Open Access: All 3137 5:13:51 PM fSekrit.exe:600 CREATE B:\test23 SUCCESS Options: Create Access: All 3138 5:13:51 PM fSekrit.exe:600 CLOSE B:\test23 SUCCESS 3139 5:13:51 PM fSekrit.exe:600 OPEN B:\test23 SUCCESS Options: Open Access: All 3140 5:13:51 PM fSekrit.exe:600 QUERY INFORMATION B:\test23 SUCCESS FileAttributeTagInformation 3141 5:13:51 PM fSekrit.exe:600 DELETE B:\test23 SUCCESS 3142 5:13:51 PM fSekrit.exe:600 CLOSE B:\test23 SUCCESS 3143 5:13:51 PM fSekrit.exe:600 QUERY INFORMATION B:\test23 NOT FOUND Attributes: Error 3144 5:13:51 PM fSekrit.exe:600 QUERY INFORMATION B:\test23 NOT FOUND Attributes: Error 3145 5:13:51 PM fSekrit.exe:600 QUERY INFORMATION B:\ SUCCESS Attributes: CDRHS 3146 5:13:51 PM fSekrit.exe:600 OPEN B:\ SUCCESS Options: Open Directory Access: All 3147 5:13:51 PM fSekrit.exe:600 DIRECTORY B:\ NO SUCH FILE FileBothDirectoryInformation: test23 3148 5:13:51 PM fSekrit.exe:600 CLOSE B:\ SUCCESS 3149 5:13:51 PM fSekrit.exe:600 CLOSE B:\ SUCCESS 3150 5:13:51 PM fSekrit.exe:600 QUERY INFORMATION B:\test23.exe NOT FOUND Attributes: Error 3151 5:13:56 PM fSekrit.exe:600 CREATE B:\test23.exe SUCCESS Options: OverwriteIf Sequential Access: All 3152 5:13:56 PM fSekrit.exe:600 QUERY INFORMATION B:\test23.exe SUCCESS FileFsAttributeInformation 3153 5:13:56 PM fSekrit.exe:600 QUERY INFORMATION B:\test23.exe SUCCESS Attributes: CRA 3154 5:13:56 PM fSekrit.exe:600 SET INFORMATION B:\test23.exe SUCCESS Length: 51200 3155 5:13:56 PM fSekrit.exe:600 WRITE B:\test23.exe SUCCESS Offset: 0 Length: 51200 3156 5:13:56 PM fSekrit.exe:600 SET INFORMATION B:\test23.exe SUCCESS FileBasicInformation 3157 5:13:56 PM fSekrit.exe:600 CLOSE B:\test23.exe SUCCESS 3158 5:13:56 PM fSekrit.exe:600 OPEN B:\test23.exe SUCCESS Options: Open Access: All 3159 5:13:56 PM fSekrit.exe:600 QUERY INFORMATION B:\test23.exe SUCCESS Length: 51200 3160 5:13:56 PM fSekrit.exe:600 READ B:\test23.exe SUCCESS Offset: 51192 Length: 8 3161 5:13:56 PM fSekrit.exe:600 CLOSE B:\test23.exe SUCCESS 3162 5:13:56 PM fSekrit.exe:600 OPEN B:\test23.exe ACCESS DENIED NT_AUTHORITY\SYSTEM
|
|
|
|
|
Logged
|
|
|
|
jfsfgdfg
Guest
|
 |
« Reply #8 on: November 17, 2007, 06:36:21 PM » |
|
Sorry to bombard the board. But in doing some more testing - I ran notepad.exe off the CD and saved to the RAM drive with no problems.
|
|
|
|
|
Logged
|
|
|
|
|
Carol Haynes
|
 |
« Reply #9 on: November 17, 2007, 06:42:14 PM » |
|
Could it be that during a save when it saves the basecode of fsekrit if the base code is readonly - it will copy as a read only file and then when you try to append the data it will fail because it can't append to a readonly file?
|
|
|
|
|
Logged
|
|
|
|
|
f0dder
|
 |
« Reply #10 on: November 17, 2007, 06:55:58 PM » |
|
Hmm, BartPE doesn't set %TEMP%? Shouldn't matter wrt. SaveAs from a blank note, though, since %TEMP% is only used when a note with embedded data is opened. I assume B:\ is the RAM drive. From the FileMon log, it seems like the file is copied okay, but opening for write (to append the note data) fails. Weird! Does the BartPE boot CD have any (always-running automagic) antivirus stuff running? Heh, googling for "ACCESS DENIED" "NT_AUTHORITY\SYSTEM" shows that this forum thread is already indexed 
|
|
|
|
|
Logged
|
 - carpe noctem
|
|
|
|
f0dder
|
 |
« Reply #11 on: November 17, 2007, 06:56:53 PM » |
|
Could it be that during a save when it saves the basecode of fsekrit if the base code is readonly - it will copy as a read only file and then when you try to append the data it will fail because it can't append to a readonly file?
I think you're spot on the sugar, baby! fSekrit uses the windows FileCopy API - it probably copies over the file attributes verbatim, which means the open-for-write after copying the base executable fails. Guess I should clear the file attributes... and obviously, not having write access to a file is different from the file having +R attribute.
|
|
|
|
« Last Edit: November 17, 2007, 06:59:30 PM by f0dder »
|
Logged
|
 - carpe noctem
|
|
|
jfsfgdfg
Guest
|
 |
« Reply #12 on: November 17, 2007, 06:58:20 PM » |
|
Carol - that may be it. I forgot to mention earlier that the file is created on the RAM drive (without the new data). And based on the FileMon data line 3153 seems to be saying the newly created file is R/O. So when the data append does come it abends.
|
|
|
|
|
Logged
|
|
|
|
|
f0dder
|
 |
« Reply #13 on: November 17, 2007, 07:09:05 PM » |
|
There, quick and easy fix after isolating the problem... Thanks for the bug report, jfsfgdfg (gosh, that's a nickname I won't be able to memorize  ), and thanks for pointing out the bug to my slow brain, Carol  Try the attached beta build and see if it fixes your problems. Don't mention the file naming, I think I need to catch some sleep... if it works out, I'll see if I can get a proper beta version (ie, readme.txt and all that) uploaded tomorrow. Been slacking off wrt. fSekrit for far too long now!
|
|
|
|
Logged
|
 - carpe noctem
|
|
|
jfsfgdfg
Guest
|
 |
« Reply #14 on: November 17, 2007, 07:29:44 PM » |
|
Bingo!!! That did it.
Thanks!!
|
|
|
|
|
Logged
|
|
|
|
|
Carol Haynes
|
 |
« Reply #15 on: November 18, 2007, 05:53:28 AM » |
|
Hurrah! I finally got something right 
|
|
|
|
|
Logged
|
|
|
|
|